Внутрішня мережа багато секційного комутатора будується на засадах мережі ОКСу та забезпечує маршрутизацію повідомлень для як внутрішніх вузлів, так зовнішніх, по відношенню до комутатора вузлів. Для всіх вузлів забезпечується курсування повідомлень всіх підсистем ОКСу: як основних, так і резервних та транзитних; для внутрішніх вузлів додатково - обробка та маршрутизація повідомлень підсистеми діагностики (DIAG).

Зовнішні вузли, що описані директивою ConnectOksNode, вважають комутатор цілісною одиницею, з унікальним поінт-кодом; поинт-код комутатора визначається відповідною директивою DefinePointCode.

До вузлів внутрішньої мережі відносяться підлеглі вузли, описані директивою ConnectOksPeer та секції комутатора, які не потребують жодного опису. Кожен вузол внутрішньої мережі може мати декілька поінт-кодів - більш того, вузли внутрішньої мережі можуть вважати комутатор ланкою локальної мережі з декількома поінт-кодами. Всі таки особливості мульти-адресної маршрутизації визначаються при описі внутрішнього вузла декількома директивами ConnectOksPeer.

Секції комутатора, що працюють по ОКСу, отримують поінт-код автоматично, в залежності від базового поінт-коду складових частин самого комутатора; при необхідності, секціям можна надати конкретний поінт-код директивою DefinePointCode. Взаємодія з вузлами внутрішньої мережі відбувається з індикатором мережі Zon. В залежності від складності моделі комутатора програма може формувати інші індикатори мереж.

Для точної настройки програми на модель комутатора використовується директива Model:, в якій вказується який саме параметр моделі комутатора уточнюється.

По замовчуванню назва комутатора формується з назви головного вхідного файлу опису комутатора - наприклад: назва файлу опису - 112-Switch.Prj - відповідно він містить опис комутатора 112. Цю назву можна явно перевизначити директивою опису моделі Model: Name:

Model: Name = Novoguj ;; назва вузла

По замовчуванню складові частини комутатора (секції) отримують послідовні поінт-коди, похідні від поінт-коду самого комутатора. Для зміни цього базису використовується директива:

Model: BasicPC = <0,4,0> ;; зміна базису

Ця директива вказує що всі складові частини комутатора отримують послідовні поінт-коди починаючи з коду 0-4-0. Увага: директива Model: BasicPC не змінює поінт-код самого комутатора, який вказується директивою DefinePointCode! В директиві Model: BasicPC можна вказати довжину діапазону поінт-кодів, які резервуються за всім комутатором для маршрутизації повідомлень диагностики.

Model: BasicPC = <0,4,0> +75 ;;

резервується 75 поінт-кодів починаючи з 0-4-0.

По замовчуванню програма BuildSwitch налаштована на аналіз опису та побудову однопроцесорного абонентського комутатора (БАДу). Для зміни цього налаштування використовується директива, в якій явно вказується тип моделі комутатора.

Model:    Type    = Abn

Цей тип моделі (він же по замовчуванню) призначений для аналізу опису типової однопроцесорної абонентської станції (дивись Абонентський кросс), та створення секційних файлів однопроцесорного комутатора з явною абонентською складовою:

• A1 - A6 - точки підключення шести потоків Ikm-30;
• C - R - точки підключення абонентських плат;

Model:    Type    = 374

Дана модель повністю “прив'язана” до комутатора на базі кроса 374 (дивись Cross374), використовуються типові позначення точок підключення потоків IKM-30, позначення каналів, секцій та інших внутрішніх ресурсів. Програма використовує засади дворівневої моделі та вважає що всі зовнішні потоки ОКСу транзитно-підняті на верхній рівень. Збудована модель враховує особливості роботи секцій в режимі комутації, вузол MTP або транзитного підняття.

Модель використовує зарезервовані позиції та назви секцій комутатора:

• A,B - позиції процесорів на верхньому рівні;
• С…O - тринадцять позицій процесорів на нижньому рівні, точки підключення шести потоків Ikm-30 з номерами 1 - 6;
• HugA,HugB - назви процесорів на верхньому рівні;
• SctC…SctO - назви процесорів на нижньому рівні;

Для уточнення параметрів моделі програма використовує директиву Model::

  Model:    WideLinksProcList = <A,B, J,K,L,M>

В цій директиві вказується список секцій комутатора між якими треба прокладати потужні міжсекційні лінки: увага це можливо тільки між секціями які побудовані на базі процесорів Ht85g (верхніх) та Pc76q (нижніх)!

Model:    Type    = 376

Ця модель “прив'язана” до комутатора на базі кроса 376 (дивись Cross376), використовує типові позначення точок підключення потоків IKM-30 та позначення каналів. Програма базується на однорівневій моделі та враховує особливості роботи секцій в режимі повної комутації; внутрішні міжсекційні з'єднання будуються на основі ОКСу.

Програма використовує зарезервовані позиції та назви секцій комутатора:

• A,B - позиції процесорів з шістьма точками (1 - 6) підключення потоків на кожній;
• SctA,SctB - назви процесорів;

Model:    Type    = 492

Цей тип моделі призначений для аналізу опису двопроцесорного комутатора з гарячим резервуванням (дивись Cross492), та створення його секційних файлів. Програма вважає, що всі двадцять потоків (01 - 20) підключені до одного комутатора A.

Model:    Type    = 395

Ця модель “прив'язана” до комутатора на базі кроса 395 (дивись Cross395). Програма базується на однорівневій моделі та враховує особливості роботи секцій в режимі повної комутації; внутрішні міжсекційні з'єднання будуються на основі ОКСу.

Програма використовує зарезервовані позиції та назви секцій комутатора:

• A,B - позиції процесорів з двадцятьма точками підключення потоків на кожній; номера потоків 01 - 20;
• SctA,SctB - назви процесорів;

Model:    Type    = HeapAbn
Model: InterConnect = <12,23>,<22,33>,<32,43>,<42,53> ;; півколо

Анонс, в процесі

Вся інформація, що приймається по ланкам сигналізації (ОКС або Pri) обробляється безпосередньо в точці підключення відповідного потоку; по внутрішній мережі вона курсує після попередньої обробки. Біти сигналізації CAS, отримані в каналі сигналізації обробляються, або в точці підключення комутованого потоку або після незначної обробки на верхньому рівні комутатора.

Директиви опису підключення потоків визначають рівень на якому комутуються тональні канали. Комутоване підключення передбачає комутацію на нижньому рівні або рівні 2Mbs - безпосередньо в точці підключення. Приклади опису комутованого підключення потоків:

  DefineCasIkm   E, 2, HP2	;; КОМУТОВАНІ знизу	xBrd+xAbn
  DefinePriIkm   M, 3, H--, 32, <-123456789ABCDEF-HIJKLMNOPQRSTUV>
  GroupCasIkm	<F1,F2>, AI1, 32, <-123456789ABCDEF-HIJKLMNOPQ-----> ;; вихід на сусідній комутовано	
  GroupPriIkm	<G1,G2>, H--

Примітка - реалізація програмою BuildSwitch моделі 374 не передбачає комутованого підключення потоків ОКСу.

Транзитне підключення, передбачає транзит тональних каналів з точки підключення на рівень 8Mbs, де і відбувається комутація цих каналів; для потоків ОКСу можливій транзит тільки на один верхній процесор (A або B); для потоків CASу - тільки на обидва верхніх процесори. Приклади опису транзитного підключення ОКСу на один верхній процесор:

  AlloctOksHway   C, 1, H--, 0A, 8--, 32, <--23456789ABCDEFGHIJKLMNOPQRSTUV>
  AlloctOksPass   D, 2, H--

В другій директиві використовується стандартна схема підняття потоку D2. Примітка - реалізація програмою BuildSwitch моделі 374 не розрізняє директиви AlloctOksHway та AlloctOksPass.

Приклади опису транзитного підключення потоків CAS на обидва верхніх процесори:

  AlloctHwa       F, 6, HP2N, 0F,      0L
  AlloctHwa       F, 6, HP2N

Примітка - транзитне підключення потоків Pri - неможливе.

В директивах транзитного підключення може вказуватись субтракт нижньої секції, через який проходить транзит тональних каналів нагору; цей субтракт автоматично визначає субтракт верхньої секції, куди потрапляють тональні канали цього потоку. Якщо цей субтракт не вказаний - буде використовуватися схема підняття по замовчуванню.

В комутаторі, побудованому на базі кросу 374, назви каналів потоків IKM-30 (наприклад D2S, F4F) складаються з трьох літер:

• D - перший символ - назва секції, від C до O;
• 2 - другий символ - потік на секції, від 1 до 6 ;
• S - третій символ - канал в потоці, від 0 до V ;

Назви каналів субтрактів верхніх процесорів (наприклад B2FC) складається з чотирьох літер:

• B - перший символ - назва секції, тільки A або B;
• 2 - другий символ - група субтрактів, відповідає секції, від 0 до D;
• F - третій символ - субтракт по 16 каналів, - A, B, C, D, E, F;
• C - четвертий символ - канал в субтракті, 16 каналів від 0 до F; в парних субтрактах, за рахунок наступних непарних, може бути 32 канали з номерами від 0 до V;

Відповідність між нижньою секцією та групами субтрактів в комутаторі:

При підйомі потоку на один процесор (A або B) діє така відповідність між потоком та субтрактом 32 канали в схемі по замовчуванню:

В цій послідовній схемі підняття потоку номер каналу потоку (32 канали від 0 до V) повністю відповідає каналу парного субтракту 32 канали; назви субтрактів A, C, E.

В схемі підйому потоку на два процесори (A та B) по замовчуванню діє така відповідність між потоком та субтрактом 16 каналів:

В цій схемі підйому канали 0 та G не піднімаються; такий підйом передбачає два способи проключення каналів через нижню секцію. Послідовний спосіб:

Послідовний спосіб використовується для підйому потоків Cas з модифікатором режиму “O”.

Спосіб з чергуванням каналів:

Цей спосіб використовується тільки для підйому потоків Cas з модифікатором “N”.

Відповідність між каналами вхідних потоків на нижніх секціях та каналами субтрактів на верхніх секціях може описуватися в довідкових таблицях всього комутатора.

Віртуальні блоки, які визначені директивами AlloctTract, відразу прив'язуються до верхніх процесорів - A та B; при чому кожний блок дублюється на обох цих процесорах, дублюються також і всі віртуальні канали. Приклад опису:

 AlloctTract  <ZY,ZZ>, --, 5, <-1234>

- директива описує два блоки ZY та ZZ; кожен з цих блоків буде створений на обох процесорах A та B. Опис віртуального каналу:

 LineAloc  vAnw,ZY3, aon1,17, 0, 0, AT,It, 0, AnyAON ,30

буде переданий в таблиці ліній обох процесорів.

Для організації міжпроцесорних зв'язків в самому комутаторі програма BuildProject (в моделі 364) використовує внутрішні напрямки та маршрути, які мають стандартизовану структуру імен, наприклад:

  Side
  Uper, UperA, UperB, UperB@C
  DownC, DownE, DownI@A

Перші чотири літери назви визначають “напрямок” внутрішнього напрямку відносно процесора, на якому він розміщеній: вбік, вгору, вниз - тобто Side, Uper, Down. Якщо цього з контексту використання назви недостатньо - додається літера процесора, в “напрямку” якого діє цей напрямок. Приклади: UperA, UperB, DownC, DownG. Якщо і цього не достатньо - додається літера процесора, на якому розміщений цей напрямок. Приклади: UperA@E, UperB@C, DownC@A, DownG@A. Тобто, назва DownG@A інтерпретується таким чином: напрямок (або маршрут) вниз на процесор G з процесора A.

Для кожної секції або вузла внутрішньої мережі програма будує взаємно узгоджені таблиці маршрутів ОКСу; окрема таблиця будується для кожного лінк-сету або тонал-сету. Як-що якийсь вузол визначений декількома директивами DefineOksPeer та використовує декілька незалежних лінк-сетів, то до назв всіх його вторинним лінк-сетів або тонал-сетів буде додано індекс з позицією лінку, приклад:

• TsBAD5 - тонал-сет на BAD5;
• TsBAD5@M3G - тонал-сет на BAD5, що базується на лінку M3G;

Для виходу на підлеглі БАДи та комутатори ЄС-11 бажано використовувати внутрішні канали ySs7 - тільки ці канали забезпечують передачу додаткової інформації для повної маршрутизації в межах самого комутатора. Також бажано щоби назви внутрішніх напрямків та маршрутів, відповідали назвам самих об'єктів. Наприклад: визначення вузла Bad1 (директива ConnectOksNode) і, відповідно, визначення напрямку Bad1 (директива DirectionStart) - це спрощує побудову зустрічних шаблонів підключення підлеглих вузлів.

Бажано що-би внутрішні вузли відключалися в локальній мережі Zon.

Всередині директиви, яка розміщена на декількох рядках, наприклад BegExtra/Reload/EndExtra, не допускається використання інших директив.