В настоящем стандарте IEC 61375
реклама
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Изображение государственного Герба Республики Казахстан
НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН
Транспорт железнодорожный
ЭЛЕКТРОННОЕ ОБОРУДОВАНИЕ ДЛЯ ПОДВИЖНОГО СОСТАВА ЖЕЛЕЗНЫХ
ДОРОГ.
СЕТИ ПОЕЗДНОЙ СВЯЗИ (TCN).
ЧАСТЬ 3-4. Сеть Ethernet для железнодорожных составов (ECN)
СТ РК IEC 61375-3-4_____
Electronic railway equipment – Train communication network (TCN) –
Part 3-4: Ethernet Consist Network
Настоящий проект стандарта
не подлежит применению до его утверждения
«Настоящий национальный стандарт является идентичным осуществлением
международного стандарта IEC 61375-3-4 и принят с разрешения СЕН, по адресу: В1000 Брюссель, пр. Марникс 17»
Комитет технического регулирования и метрологии
Министерства по инвестициям и развитию
Республики Казахстан
(Госстандарт)
Астана
i
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
ПРЕДИСЛОВИЕ
1 ПОДГОТОВЛЕН И ВНЕСЕН Акционерным обществом
транспорта и коммуникаций им. М.Тынышпаева».
«Казахская академия
2 Утвержден и введен в действие Приказом Председателя Комитета технического
регулирования и метрологии Министерства по инвестициям и развитию Республики
Казахстан от ________ № ______
3 Настоящий стандарт идентичен международному стандарту
IEC 613753-4 Electronic railway equipment – Train communication network (TCN) – Part 3-4: Ethernet Consist
Network (Электронное оборудование для подвижного состава железных дорог. Сети поездной
связи (TCN). Часть 3-4. Сеть Ethernet для железнодорожных составов (ECN).
Международный стандарт IEC 61375-3-4 разработан Европейским техническим
комитетом по стандартизации CEN/TC 256 «Railway applications» (Приспособления,
применяемые на железной дороге).
Перевод с английского языка (en).
Официальные экземпляры международных стандартов, на основе которых разработан
настоящий стандарт, и на которые даны ссылки, имеются в Единном Государственном фонде
нормативно – технических документов.
Степень соответствия - идентичная (IDT).
4 В настоящем стандарте реализованы положения Закона Республики Казахстан «О
техническом регулировании» от 9 ноября 2004 года № 603-II и Закона Республики Казахстан
«О железнодорожном транспорте» от 8 декабря 2001 года № 266-II. (с изменениями и
дополнениями по состоянию на 24.12.2012 г.),
5 СРОК ПЕРВОЙ ПРОВЕРКИ
проверки
5 лет
20____ год
Периодичность
6 ВВЕДЕН ВПЕРВЫЕ
Информация об изменениях к настоящему стандарту публикуется в ежегодно
издаваемом информационном указателе «Нормативные документы по стандартизации», а
текст изменений и поправок – в ежемесячно издаваемых информационных указателях
«Национальные стандарты». В случае пересмотра (замены) или отмены настоящего
стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом
информационном указателе «Национальные стандарты».
Настоящий стандарт не может быть полностью или частично воспроизведен,
тиражирован и распространен в качестве официального издания без разрешения Комитета
технического регулирования и метрологии Министерства по инвестициям и развитию
Республики Казахстан.
ii
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Содержание
Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины, определения, символы, сокращения и условные обозначения
3.1 Термины и определения
3.2 Сокращения и символы
3.3 Условные обозначения
3.3.1 Определение нумерации битов
3.3.2 Определение порядка байтов
3.3.3 Тип данных
4. Общие положения
4.1 Общие данные
4.2 Архитектура
4.2.1 Сетевая структура
4.2.2 Сетевая топология
4.2.3 Классификация конечных устройств
4.2.4 Типы сетевых устройства и классификация сетевых коммутаторов
состава
4.3 Тип данных
4.4 Функции и услуги
4.5 Резервирование
4.5.1 Общие данные
4.5.2 Определения
4.5.3 Резервирование, осуществляемое на сетевом уровне
4.5.4 Резервирование осуществляемое на уровне конечных устройств
4.6 Качество обслуживания
4.6.1 Общие данные
4.6.2 Уровень приоритета
4.6.3 Назначение уровня приоритета
4.6.4 Поведение коммутатора состава
4.6.5 Ограничение скорости
4.6.6 Формирование уровня выхода
4.7 IP-адрес и соответствующие определения
4.7.1 Сетевой адрес состава
4.7.2 Сетевой адрес поезда
4.7.3 Адрес группы
4.7.4 Разрешение имени и определение имени
4.8 IP-адрес и управление конфигурацией сети
4.8.1 Управление сетевым адресом состава
4.8.2 Управление сетевым адресом поезда
4.8.3 Статические параметры конфигурации сети
4.8.4 Параметры конфигурации сетевого узла (DHCP)
4.8.5 IP-адрес управления для резервирования
4.9 Интерфейс сетевого устройства
4.9.1 Общие данные
4.9.2 Функциональные требования
4.9.3 Требования к эффективности
iii
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
4.9.4 Физический уровень
4.9.5 Канальный уровень
4.9.6 Сетевой уровень
4.9.7 Транспортный режим
4.9.8 Применение уровня
4.10 Интерфейс конечного устройства
4.10.1 Общие данные
4.10.2 Физический уровень
4.10.3 Канальный уровень
4.10.4 Сетевой уровень
4.10.5 Транспортный уровень
4.10.6 Прикладной уровень
4.11 Функции шлюза
4.11.1 Функции шлюза WTB
4.11.2 Функции шлюза ETB
4.12 Управление сетью
4.12.1 ECN управление сетью
4.12.2 WTB управление сетью
4.12.3 ETB управление сетью
5. Тест соответствия
Приложения
iv
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН
Транспорт железнодорожный
ЭЛЕКТРОННОЕ ОБОРУДОВАНИЕ ДЛЯ ПОДВИЖНОГО СОСТАВА ЖЕЛЕЗНЫХ
ДОРОГ.
СЕТИ ПОЕЗДНОЙ СВЯЗИ (TCN).
ЧАСТЬ 3-4. Сеть Ethernet для железнодорожных составов (ECN)
Дата введения
1. Область применения
Эта часть IEC (МЭК) 61375 определяет сеть передачи данных на основе технологии
Ethernet для железнодорожных составов (ECN).
Применимость этой части стандарта IEC (МЭК) 61375 позволяет производить прямую
коммуникацию отдельных транспортных средств в вагонах открытого типа в международном
сообщении.
Эта часть стандарта IEC (МЭК) 61375 может быть дополнительно применима к
вагонам закрытого типа и для подвижного состава железных дорог, в зависимости от
согласования между Покупателем и Поставщиком
2. Нормативные ссылки
В настоящем стандарте использованы полностью или частично ссылки на следующие
нормативные документы, обязательные для его применения. Для датированных ссылок
применяют только указанное издание ссылочного документа, для недатированных ссылок
применяют последнее издание ссылочного документа (включая все его изменения):
IEC (МЭК) 61076-2-101, Соединители для электронного оборудования. Требования к
продукции. Часть 2-101. Круглые соединители. Частные технические условия на соединители
М12 с фиксацией винтом
IEC (МЭК) 61076-3-104, Соединители для электронной аппаратуры. Требования к
продукции. Часть 3-104. Частные технические условия для 8-канальных стационарных
соединителей без экранирования для передачи данных на частотах до 1000 МГц включительно
IEC (МЭК) 61156-6, Кабели многожильные и симметричные парной/четверной скрутки
для цифровой связи. Часть 6. Кабели симметричные парной/четверной скрутки с
характеристиками передачи до 1000 МГц (включительно). Проводка в рабочей зоне.
Групповые технические условия
IEC (МЭК) 61375-1, Оборудование электронное железнодорожное. Сеть поездной
радиосвязи (TCN). Часть 1. Общая архитектура
IEC (МЭК) 61375-2-1, Оборудование электронное железнодорожное. Сеть поездной
радиосвязи (TCN). Часть 2-1. Проводная поездная шина (WTB)
IEC (МЭК) 61375-2-5, Оборудование электронное железнодорожное. Сеть поездной
связи (TCN). Часть 2-5. Поездная магистральная шина Ethernet
IEC (МЭК) 62439 (все части), Промышленные сети связи. Сети промышленной
автоматизации с высокой готовностью.
5
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
ГОСТ Р ИСО / IEC (МЭК) 7498, Информационные технологии - Взаимосвязь
открытых систем (OSI), Базовая эталонная модель.
ГОСТ Р ИСО / IEC (МЭК) 8824 (все части), Информационные технологии – Абстрактно
синтаксическая нотация версии один (ASN.1)
ГОСТ Р ИСО / IEC (МЭК) 11801, Информационные технологии - Прокладка
кабелей по схеме общего назначения в помещениях пользователей телекоммуникационных
систем
TIA / EIA-568-B, Стандарт телекоммуникационных кабельных систем коммерческих
зданий. Часть 1: Общие требования
ANSI X3.263: 1995, EN-Информационные технологии – Технология FDDI
оптоволоконный интерфейс распределенных данных - маркерное (или токенное) кольцо
Token Ring для витой пары, зависящей от физической среды (TP-PMD) (номер заказа ANSI
INCITS 263)
IEEE 802.1D — Стандарт IEEE для локальных и городских сетей, логика работы моста
по протоколу MAC.
IEEE 802.1Q - Стандарт IEEE для локальных и городских сетей построение
виртуальных локальных сетей (Virtual LAN, VLAN) с помощью мостов/коммутаторов
IEEE 802.3, IEEE стандарт для информационных технологий - Телекоммуникации и
обмен информацией между системами локальных и городских сетей - Особые требования Часть 3: Стандарт на метод коллективного доступа для локальных сетей CSMA/CD и на
физический уровень.
3. Термины, определения, символы, сокращения и условные обозначения
3.1 Термины и определения
Для целей настоящего документа применяются термины и определения
3.1.1 Функция автопереговоров (auto-negotiation) - позволяет двум устройствам,
соединенным одной линией связи, автоматически, без вмешательства оператора, выбрать
наиболее высокоскоростной режим работы, который будет поддерживается обоими
устройствами; например полный / полудуплекс режим, скорость передачи.
3.1.2 Автоматическое определение полярности (auto polarity) - функция
автоматического определения полярности автоматически определяет и корректирует
полярность.
3.1.3 Функция кроссовер (crossover function) - cоединение (внешнее или
внутреннее) передатчика на одном конце коммуникационного канала с приемником на
другом его конце.
3.1.4 Полный дуплексный режим (full duplex) - функция приемопередатчика,
позволяющая одновременно получать и передавать сигналы на двух дискретных частотах.
3.1.5 Связь интра-кар (intra-car connection) соединение (связь) между
устройствами связи внутри трансторта.
3.1.6 Связь интер-кар (inter-car connection) соединение (связь)
коммуникационными устройствами в интерфейсе между двумя транспортом, исключая
интерфейс между составом поезда.
3.1.7 Канальный уровень (link layer) — второй уровень модели взаимодействия
открытых систем (OSI), может взаимодействовать с одним или несколькими физическими
уровнями, контролируя и управляя этим взаимодействием.
6
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
3.1.8 Физический уровень (physical layer) – самый нижний уровень OSI,
непосредственно осуществляющий передачу потока данных по физической среде.
3.1.9 Технология PoE (power over Ethernet) технология, позволяющая передавать
удалённому устройству электрическую энергию вместе с данными, через стандартную витую
пару в сети Ethernet. Данная технология предназначается для IP-телефонии, точек доступа
беспроводных сетей, IP-камер, сетевых концентраторов и других устройств, к которым
нежелательно или невозможно проводить отдельный электрический кабель.
3.1.10 Уровень представлений (presentation layer) - уровень модели OSI,
обеспечивающий преобразование и представление данных в нужном формате.
3.1.11 Сеансовый уровень (session layer) - это уровень, определяющий процедуру
проведения сеансов между пользователями или прикладными процессами.
3.1.12 Тэг (tag) - поле в MAC кадре стандарта IEEE 802.3, который вставлен исходной
области адресного поля MAC.
3.1.13 Токен (token) –это сигнал, который используют для Управления доступом к
среде во избежание конфликтов, и передачи между устройствами связи.
3.1.14 Логическая («виртуальная») локальная компьютерная сеть (virtual LAN)
представляющая собой группу устройств, взаимодействующие между собой на канальном
уровне, при подключении к разным сетевым коммутаторам. И наоборот, устройства,
находящиеся в разных VLAN-ах изолированы друг-друга на канальном уровне, даже при
подключении к одному коммутатору (взаимодействие таких устройств возможно только на
сетевом и более высоких уровнях).
3.2 Символы и сокращения
ACK Acknowledgement
подтверждение приёма, квитирование.
ACM Access Control Machine
устройство управления доступом
ALG Application Layer Gateway
шлюз прикладного уровня
ANSI American National Standard Institute a
standardization body in the United States
ARP Address Resolution Protocol
объединение американских промышленных и
деловых групп, разрабатывающее торговые и
коммуникационные стандарты
протокол определения адреса
ASN.1 Abstract Syntax Notation Number 1
on data presentation (ISO/IEC 8824)
язык для описания абстрактного синтаксиса
данных (ASN.1) ГОСТ Р ИСО/МЭК 8824
AWG American Wire Gauge
американский стандарт калибра проводов
bps bits per second
бит в секунду, базовая единица измерения
скорости передачи информации
BT Bit Time
битовый интервал
CCF Common Cause Failure
отказы общей причины, общего
происхождения
CNN Consist Network Node
сетевой узел
CS Consist Switch
сетевой коммутатор (Ethernet переключатель)
7
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
DA Destination Address
адрес назначения
DHCP Dynamic Host Configuration Protocol
протокол динамической конфигурации
сетевого узла (хоста)
DI Data In
входные данные
DNS Domain Name System
система доменных имён
DO Data Out
выходные данные
DSCP Differentiated Services Code Point,
defined in RFC 2474
точка кода дифференцированных услуг
ECN Ethernet Consist Network
сеть Ethernet железнодорожного состава
ED End Device
конечное устройство
EIA Electronics Industries Association, a
standardisation body in the United States
альянс
отраслей
электронной
промышленности. Расположенная в США
профессиональная
организация,
разрабатывающая
электрические
и
функциональные стандарты
EMC electro-magnetic compatibility
электромагнитная совместимость
EMU Electric Multiple Unit
электропоезд
ETB Ethernet Train Backbone
хребтовая сеть поезда (ETB)
ExP External Port
внешний порт
FCS Frame Check Sequence
контрольная последовательность кадра
FTP File Transfer Protocol
протокол передачи файлов
FQDN Full Qualified Domain Name
полное доменное имя
HTTP Hypertext Transfer Protocol
протокол передачи гипертекста
ICMP Internet Control Message Protocol
протокол управляющих сообщений
Интернета
IEEE Institute of Electrical and Electronics
Engineers, New York
международный института инженеровэлектриков и электронщиков (IEEE, НьюЙорк, США)
IETF Internet Engineering Task Force
инженерный совет Интернета
IGMP Internet Group Management Protocol
протокол управления группами Internet
InP Internal Port
внутренний порт
I/O Input and Output
ввод и вывод
IP Internet Protocol
межсетевой протокол
8
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
LAN Local Area Network
локальная вычислительная сеть
LPR Local Port for Reception
локальный порт для приема
LPT Local Port for Transmission
локальный порт для передачи
LSB Least Significant Bit
младший значащий бит
MAU Medium Attachment Unit
управление доступом к среде — подуровень
канального (второго) уровня модели OSI,
протокол, используемый для определения
способа получения доступа рабочих станций
к среде передач
блок подключения к среде
MD Message Data
данные сообщения
MDI Media Dependent Interface
интерфейс, зависящий от передающей среды
MRP Media Redundancy Protocol
протокол избыточности среды
MDI-X MDI implementing crossover
function
интерфейс, зависящий от передающей среды
с перекрестным соединением
MAC Medium Access Control, a sub-layer
within the Link Layer ruling which device is
entitled to send on the bus
MSB Most Significant Bit
старший значащий бит
MTBF Mean Time Between Failures
средняя наработка на отказ
MVB Multifunction Vehicle Bus
многофункциональная поездная шина
NAT Network Address Translation
преобразование сетевых адресов
ND Network Device
сетевое оборудование
NTP Network Time Protocol
протокол синхронизации времени по
компьютерной сети
OSI Open System Interconnection, a
universal communication model defined in
the ISO/IEC 7498
открытое системное соединение, OSI
OSPF Open Shortest Path First
открытый протокол выбора кратчайшего
маршрута
PC Personal Computer
персональный компьютер
PCS Physical Coding Sublayer
подуровень физического кодирования
PD Process Data
данные процесса
PHY Physical Layer, Physical Layer device
физический слой, физическое устройство
9
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
cлоя
PMA Physical Media Attachment
подключение к физической среде
PMD Physical Medium Dependent
уровень, зависящий от физической среды
PoE Power over Ethernet
технология, позволяющая передавать
удалённому устройству вместе с данными
электрическую энергию через стандартную
витую пару в сети Ethernet
QoS Quality of service
качество обслуживания
RD Receive Data
принимаемые данные
RDA Receive Data Amplified
усилитель принимаемых данных
RFC Request for Comments, Internet
Standard published by the Internet
Engineering Task Force (IETF)
запросы на комментарии (серия документов
IETF)
R-NAT Railway Network Address
Translation
преобразование сетевых адресов поездов
RX Receive
получение данных
SFD Start Frame Delimiter
ограничитель начала кадра
SNMP Simple Network Management
Protocol
простой протокол сетевого управления
SNTP Simple Network Time Protocol
упрощенный протокол синхронизации
времени по компьютерной сети
SS Signal Status
статус сигнала
STP Shielded Twisted Pair cable, a cable in
which each pair of two conductors are twisted
together and shielded
экранированная витая пара
TBN Train Backbone Node
магистральный поездной узел
TCN Train Communication Network, a set of
communicating vehicle and Train Backbones
сеть поездной связи
TCP Transmission Control Protocol
протокол управления передачей
TD Transmit Data
передаваемые данные
TDA Transmit Data Amplified
усилитель передачи данных
TDRD Transmit Data and Receive Data
передаваемые данные и принимаемые данные
10
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
TFLPR Timer for Failure of Local Port for
Reception
таймер сбоя локального порта приема
TFTP Trivial File Transfer Protocol
тривиальный протокол передачи файла
TFTPU Timer for Failure of Trunk Port Up
link
таймер сбоя транкового порта Up link
TIA Telecommunications Industry
Association
ассоциация телекоммуникационной
промышленности
TLT Timer for Limit Time
таймер ограничения времени
TNM Train Network Management
управление сетью железных дорог
TNMS Timer for CNN Management Sending
таймер
для
управления
отправкой
административное
управление
сетью
пользователя CNN
TNORD Timer for No Reception Down link
таймер для отсутствия приема Down link
TPCM Trunk Port Control Machine
машина контроля транкового порта
TPD Trunk Port Down link
транковый порт Down link
TPU Trunk Port UP link
транковый порт Up link
TPUD Trunk Port Up link and Down link
транковый порт Up link и Down link
TREQ Timer for Transmit Request
таймер для передачи запроса
TRLPR Timer for Recovery of Local Port for
Reception
таймер для восстановления локального порта
приема данных
TRTPD Timer for Recovery of Trunk Port
Down link
таймер для восстановления транкового порта
Down link
TRTPU Timer for Recovery of Trunk Port Up таймер для восстановления транкового порта
link
Up link
TRRC Transmission, Reception and Repeat
Control
контроль передачи, приема и повторной
передачи данных
TTRT Target Token Rotation Timer
таймер вращения маркера
TX Transmit
Передатчик
UDP User Datagram Protocol
протокол пользовательских датаграмм
UTP Unshielded Twisted Pair cable, a cable
in which each pair of two conductors are
twisted together and not shielded
неэкранированная витая пара, представляет
собой одну или несколько пар изолированных
проводников, скрученных между собой (с
11
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
небольшим числом витков на единицу
длины), покрытых пластиковой оболочкой.
VLAN Virtual LAN
логическая («виртуальная») локальная
компьютерная сеть
VTLT Value to Timer for Limit Time
значение таймера ограниченного времени
VTREQ Value to Timer for Transmit Request
значение таймера передачи запроса
VTTRT Value to Target Token Rotation
Timer
значение переменной таймера
вращения маркера
WTB Wire Train Bus
проводная поездная шин
3.3 Условные обозначения
В настоящем стандарте IEC 61375-1 применяются следующие обозначения:
3.3.1 Определение нумерации битов
Для представления информации в настоящем стандарте определена нумерация битов,
используя двоичный способ кодирования, оценивают в байте или слове.
3.3.2 Определение порядка байтов
Для представления информации в настоящем стандарте при кодировании применяется
порядок байтов от старшего к младшему, если не указано иное.
Формат информации определен в графической форме, в последующем в табличном виде,
чтобы показать детали. Октеты в порядке слева направо и сверху вниз, кодируются в формате
кадре Ethernet, если другое не указано.
3.3.3 Тип данных
3.3.3.1 Общее понятие
Для представления информации в настоящем стандарте типы данных закодированны согласно
ASN.1. Однако правила ASN.1 не применены, чтобы проигнорировать идентификатор
объекта, длину и конечный учосток октеты. Типы данных, которые добавлены, следующие.
Примечание. Большинство значений такое же, как определено в IEC 61375-2-1.
3.3.3.2 Булева типа данных или логический
Простой тип данных могут иметь лишь одно из двух состояний — «истина» или «ложь».
Примечание. Большинство значений является таким же как определено в IEC 61375-2-1.
Синтаксис выглядит следующим образом:
12
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
BooleanType::= BOOLEAN1
Пример закодирован как один бит. При изучении булевых функций по традиции используют
символы 0 и 1, число 1 трактуется как «истина», а ноль — как «ложь».
3.3.3.3 Беззнаковый целочисленный тип данных
Один из простейших и самых распространённых типов данных в языках
программирования, представлен положительными числами и нулем.
Определены три типа, у которых есть фиксированный размер в битах, определенных
постфиксацией #, который равняется 8, 16, или 32.
Примечание. Большинство значений является таким же как определено в IEC 61375-2-1, но #
ограничен до 8, 16, и 32.
Синтаксис выглядит следующим образом:
::= UNSIGNED#, (# = {8,16,32})
Диапазон UNSIGNED8: 0..255
Диапазон UNSIGNED16: 0..65535
Диапазон UNSIGNED32: 0..2
32
–1
Они должны быть закодированы в двоичном числе, состоящем из 8, 16, или 32 бита.
3.3.3.4 Тип данных octet string
Определение типа octet string должно соответствовать ASN.1. Тип данных, который должен
быть закодирован как последовательные октеты в порядке их появления в значении данных
4 Основная часть
4.1 Общие данные
Глава 4 определяет общие требования и технические характеристики для конечных устройств,
системного оборудования, магистрального поездного узла (TBN), и всей сети Ethernet для
железнодорожных составов (ECN).
4.2 Архитектура
4.2.1 Сетевая структура
Логическая архитектура сети Ethernet для железнодорожных составов (ECN) показана на
рисунке1. Ethernet сеть (ECN) соединяет конечные устройства, расположенные в одном
составе. Подключение сети Ethernet (ECN) к магистрали поезда должно быть через один
магиcтральный поездной узел (TBN) или комплект резервных поездных узлов (TBN)
магистрали поезда.Это общее требование, что только один поездной узел (TBN) может
пересылать пакеты данных пользователя между сетью Ethernet для железнодорожных
составов (ECN) и магистралью поезда. Тем не менее, все резервные поездные узлы (TBN)
13
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
могут дополнительно пересылать пакеты данных пользователя между сетью Ethernet (ECN) и
магистралью поезда.
Примечание 1. В случае применения поездной шины вагонного состава WTB, только
один магиcтральный поездной узел (TBN) активен для одной Ethernet сети (ECN). В случае
применения хребтовой сети поезда (ETB), все резервные поездные узлы (TBN) активны.
Смотрите МЭК (IEC) 61375-2-1 и 61375-2-5.
Сеть Ethernet для железнодорожных составов (ECN) должна быть основана на
коммутируемой сети Ethernet. Сеть Ethernet (ECN) состоит из сетевых коммутаторов состава,
разъемов, кабелей, и дополнительно повторителей и передатчиков кадра данных между
конечными устройствами и конечными устройствами и магиcтральным поездным узлом
(TBN). Путевая сеть ECN может состоять из подсетей внутри, а маршрутизаторы,
соединяющие подсети могут быть развернуты.
Один состав может иметь одну сеть или несколько сетей Ethernet для железнодорожных
составов (ECN), и эти Ethernet сети могут находиться на либо нет на поверхности одной и той
же магистрали поезда. Конечное устройство может подключаться к различным поездным
cетям через разные интерфейсы устройств, но считается, что физическое конечное устройство
имеет несколько логических конечных устройств в себе.
Пример. Конечное устройство может соединиться с сетью железнодорожного состава
для услуг по контролю поезда и соединиться, для мультимедийных услуг.
Ethernet порты между конечными устройствами и сетевыми коммутаторами состава; и
между магиcтральным поездным узлом (TBN) и сетевыми коммутаторами состава должны
соответствовать требованиям стандарта IEEE 802.3. Ethernet порты для соединения сетевых
коммутаторов состава должны соответствовать требованиям стандарта IEEE 802.3, но не в
обязательном порядке с целью достижения особенных железнодорожных требований.
Топология сети Ethernet для железнодорожных составов (ECN) может изменяться с
внедрением сети Ethernet ECN, но общие требования определены данной частью стандарта.
Примечание 2. Поэтому сетевые коммутаторы состава на рисунке 1, не подключены
напрямую.
Магиcтральный поездной узел (TBN), к которому подсоединяется сеть Ethernet (ECN)
обеспечивает функцию шлюза, которая осуществляет передачу данных между сетью Ethernet
(ECN) и магистралью поезда. Магистраль поезда оснащают узлом сязи Ethernet (ECN) для
присоединения к хребтовой поездной сети WTB или ETB (Ethernet). Связь между сетью
состава может быть возможной прямо или косвенно по магистрали поезда; т.е. функция шлюза
может быть осуществлена как функция направления в сетевом слое или как шлюз прикладного
уровня.
4.2.2 Сетевая топология
Любая физическая топология может быть развернута в соответствии с требованиями
приложений, но сеть Ethernet состава (ECN) не должен формировать петлю или петли в
логической топологии. В списке ниже приведены примеры.
Способы соединения сетевых устройств физических топологии Ethernet сети (ECN)
могут быть в виде линии, кольца, либо цепи, либо другой, в целях реализации различных
уровней резервирования. Ethernet сети состава (ECN) могут иметь одну или более подсетей.
Базовые топологии линия, кольцо и цепная топология введены в МЭК (IEC) 61375-1.
Для резервирования связи конечного устройство, конечное устройство может быть
подключено к двум различным сетевым коммутаторам состава с помощью двух независимых
14
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
каналов связи, который содержится в стандарте МЭК (IEC) 61375-1, а также определен как
двойное (дублированное) подключение в главе 4.5.4 а данном стандарте.
Рисунок 2 показывает примеры Ethernet сети состава с различной физической
топологией и резервирования связи конечного устройство.
Примечание. См также главу 4.5 и приложение А, касательно топологии с точки зрения
резервирования.
1. Линейная топология
2. Линейная топология (параллельная сеть резервирования) с двойным (дублированным)
подключением
3. Кольцевая топология
4. Кольцевая топология с двойным (дублированным) подключением
5. Цепная топология с двойным (дублированным) подключением
Рисунок 2 - Примеры Ethernet сети состава (ECN) с различной физической топологией
5.2.3 Классификация конечных устройств
Согласно установке конечные устройства классифицируются, как показано в таблице 1.
Таблица 1 - Классификация конечных устройств (1)
Классификация конечных устройств
Временные конечные устройства
Описание
Временные конечные устройства, это
конечные устройства, которое не сильно
закреплены на основу поезда, и соединены с
сетью Ethernet сети состава (ECN) временно
с целью
обеспечения обслуживания,
например.
Персональный
компьютер,
который
используют
для
контроля эксплуатационного
состояния
оборудования,
является
типичным
временным конечным устройством.
Стандартные конечные устройства
Стандартные конечные устройства, это
конечные устройства, который неподвижно
закреплены к основе поезде. Это основной
класс конечных устройств.
Стандартные конечные устройства, в свою очередь, согласно требованиям связи
классифицируются, как показано в таблице 2.
Таблица 2 - Классификация конечных устройств (2)
Классификация конечных устройств
Локальное конечное устройство состава
15
Описание
Локальное конечное устройство состава –
это конечное устройство, которое связывает
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Конечные устройства поездной связи
Конечное устройство осведомленное
поездной топологией
только устройства одной поездной сети
Ethernet
(ECN). Этот класс конечных
устройств не всегда нуждается в топологии
поезда.
Конечные устройства поездной связи – это
устройства, которые связывают магистраль
поезда с устройствами поездной связи или
напрямую соединяются с магистральными
поездными узлами (TBN). Этот класс
конечных устройств должен отслеживать,
изменения топологии поезда, чтобы после
внедрения не связываться с неправильными
устройствами.
Однако устройство не должно знать
топологию поезда отдельно; т.е. оно не
должно начинать связь
по магистрали
поезда. Отчет топографии магистрали поезда
– это типичный пример информации
топологии поезда. Конечные устройства
поездной связи должны отвечать тем же
требованиям, что и локальные конечные
устройства состава.
Конечное
устройство
осведомленное
поездной топологией – это устройство,
которое связывает по магистрали поезда и
должно
знать
топологию
поезда,
соответственно сетевые адреса за поездной
сетью Ethernet (ECN).
Например, контроллер (конечное устройство
осведомленное
поездной
топологией)
соединяет
устройства
ввода/вывода
(конечные устройства поездной связи)
удаленной поездной сетью Ethernet (ECN) по
основе магистрали.
В этом случае, контроллер должен знать
адреса удаленных устройств ввода/вывода
при помощи базы данных топологии поезда,
но отдаленные устройства ввода/вывода не
должны это зачастую знать. Поездная
топология конечных устройств должна
отвечать тем же требованиям, что и
конечные устройства поездной связи.
Примечание. Протоколы, обеспечивающие информацию относительно топологии поезда,
определены в стандарте МЭК (IEC) 61375-2-3.
16
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
4.2.4 Типы сетевых устройства и классификация сетевых коммутаторов состава
Сетевые устройства в поездной сети Ethernet (ECN) классифицированы с точки зрения
функциональности как показано в Таблице 3.
Таблица 3 – Типы сетевых устройств
Типы сетевых устройств
Описание
Повторитель
Этот тип сетевого устройства может быть использован для
соблюдения физических правил Ethernet между двумя
устройствами связи. Основная
характеристика этого
сетевого устройства быть прозрачным, насколько это
возможно для всех протоколов от канального уровня и
выше.
Сетевые
состава
Маршрутизатор
коммутаторы Этот тип сетевого устройства является основным типом для
поездной сети Ethernet (ECN). Сетевые коммутаторы
состава должны передавать кадры в канальном уровне
между двумя устройствами. Сетевые коммутаторы состава
по функциям классифицированы, на управляемые и
неуправляемые, как определено в таблице 4.
Это сетевое устройство, которое имеет, по крайней мере два
IP-интерфейса и обеспечивает связь между множеством IP
подсетей в сети слоя. Магистральный поездной узел (TBN)
между хребтовой сетью поезда (ETB) и поездной сетью
Ethernet (ECN)
может содержать маршрутизаторы
специализированные для
бортовой связи поездов.
Маршрутизаторы магистрального поездного узла (TBN)
могут
реализовать
некоторые
обычные
сетевые
приложения, такие как сервер протокола динамической
конфигурации сетевого узла (DHCP), сервер систем
доменных имён (DNS), сервер протокола синхронизации
времени по компьютерной сети (NTP), и так далее.
Примечание: Магистральный поездной узел (TBN) между
хребтовой сетью поезда (ETB) и поездной сетью Ethernet
(ECN) , также может быть шлюзом приложений. DHCP,
DNS, NTP-серверы также могут находиться в других
сетевых и конечных устройствах.
Сетевые коммутаторы состава по функциям классифицированы, как показано в Таблице 4.
Таблица 4 – Классификация сетевых коммутаторов состава
17
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Сетевые коммутаторы
состава
Описание
Неуправляемые
сетевые Неуправляемые сетевые коммутаторы состава это сетевые
коммутаторы состава
коммутаторы, у которых только ограниченные функции.
Как минимум, этот класс сетевых коммутаторов должен
поддержать стандарт IEEE 802.1D, указанный в главе 4.9, но
не обязан поддерживать дополнительные функции, такие
как интерактивное управление и функции
IPкоммуникации.
Управляемые
сетевые Управляемые сетевые коммутаторы состава это сетевые
коммутаторы состава
коммутаторы которые имеют функции MAC мост,
интерактивное управление, IP-коммуникации и так
далее.Управляемые сетевые коммутаторы должны отвечать
тем же требованиям, что и неуправляемые сетевые
коммутаторы
4.3
Тип данных
Стандарт МЭК (IEC) 61375-1 определяет 5 основных типа данных:
Данные по контролю
Данные обработки
Данные о сообщении
Данные о потоке
Данные о максимальном усилии
Пример. Сообщения, обменивающиеся между сетевыми коммутаторами состава, с целью
управления сетевой топологией, являются типичными примерами данных контроля,
используемых в поездных Ethernet сетях (ECN). Таблица 5 показывает типичные параметры
обслуживания для каждого типа данных и Таблица 6 показывает типичные значения
параметров обслуживания для каждого типа данных. Однако конкретное определение
параметров обслуживания и значения параметров определяется в соответствии с
требованиями от конкретных приложений, сеть ECN должны поддерживать эти типичные
значения параметров обслуживания для каждого типа данных.
Примечание. Качество обслуживания используется для реализации сервисных параметров.
См гл. 4.6.
Таблица 5 – Параметры обслуживания типа данных
Параметры
обслуживания
Время цикла
Описание
Единица
измерения
Время между двумя последовательными кадрами, которые Секунды
передаются циклически.
18
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Объем данных
Длина поля данных (полезная
переданном в канальный уровень.
нагрузка)
в
кадре, Октеты
Задержка
Время передачи кадра в канальном уровне между двумя
конечными устройствами.
Секунды
Время начала передачи, не должно быть позже, чем начало
передачи данных на канальном уровне обслуживания в
стеке протоколов связи.
Время конца передачи не должно быть раньше приема
кадра всех данных в канальном уровне в стеке протоколов
связи.
Дрожание
Различие в период передачи для последующих кадров
передач.
Секунды
Таблица 6 – Типичные значения параметров обслуживания типа данных
Тип даты
Параметры обслуживания
Значение
минимальное время цикла
20 мс
максимальный объем данных
1 500 октетов
максимальная задержка
10 мс
максимальное дрожание
10 мс
минимальное время цикла
не применимо
максимальный объем данных
1 500 октетов
максимальная задержка
100 мс
Данные обработки
Данные о сообщении
максимальное дрожание
Данные о потоке
19
не применимо
минимальное время цикла
не применимо
максимальный объем данных
1 500 октетов
максимальная задержка
125 мс
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Данные о максимальном
усилии
Данные по контролю
максимальное дрожание
25 мс
минимальное время цикла
не применимо
максимальный объем данных
1 500 октетов
максимальная задержка
не применимо
максимальное дрожание
не применимо
минимальное время цикла
10 мс
максимальный объем данных
1 500 октетов
максимальная задержка
10 мс
максимальное дрожание
10 мс
4.4 Функции и услуги
Функции и услуги, сети Ethernet (ECN) перечислены ниже.
Ретрансляция кадров
Сеть (ECN) должна принимать кадры MAC, определенные в стандарте IEEE 802.3 с конечных
устройств и передавать MAC кадры назначенным конечным устройствам, по определенным
полям адресов MAC кадров. Для реализации этой функции, технические характеристики
сетевых коммутаторы состава должны быть в состоянии передать MAC кадры основные (без
тегов) и с тегами.
Логическая («виртуальная») локальная компьютерная сеть LAN
Сеть (ECN) должна быть в состоянии обеспечить функции виртуальной локальной
компьютерной сети LAN, определенные в стандарте IEEE 802.1Q. Функции VLAN,
требуемые в сети Ethernet для железнодорожных составов (ECN) определены в главе 4.9.
Примечание 1. Тщательное конфигурация VLAN является важной, потому что ошибки
конфигурации легко могут полностью изолировать конечные устройства.
Управление резервированием
Сеть (ECN) может обеспечить резервирование и управление резервированием, когда это
необходимо согласно требованиям приложении. ECN резервирование определяется в главе
4.5. Внедрение ECN может и не обеспечить резервирование, когда в этом нет необходимости.
Качество обслуживания (QoS)
20
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Сеть (ECN) может обеспечить качество обслуживания посредством приоритезации трафика,
когда это необходимо согласно требованиям приложении. Качество обслуживания в ECN
определяется в главе 4.6.
Функции сетевого шлюза
Когда сеть ECN соединяется к хребтовой магистрали поезда, магистральный поездной узел
(TBN) должен обеспечить функции сетевого шлюза для передачи данных между магистралью
поезда и сетью. Функции сетевого шлюза определены в главе 4.11.
Управление сетью железных дорог
Когда сеть ECN соединяется к хребтовой магистрали поезда, магистральный поездной узел
(TBN) обеспечивает управление сетью железных дорог, согласно той хребтовой магистрали
поезда. Управление сетью железных дорог определено в главе 4.12.
Сеть Ethernet для железнодорожных составов (ECN) обеспечивает выполнение, упомянутых
ниже функции и услуг.
Динамическое назначение IP-адреса
Сеть Ethernet для железнодорожных составов (ECN) обеспечивает функции динамического
назначения IP-адресов устройств. Устройства также могут использовать назначение
статического IP адреса. Требования для назначения IP-адреса и его управления определены в
главах 4.7 и 4.8.
Разрешение DNS имени
Сеть Ethernet для железнодорожных составов (ECN) обеспечивает функции по разрешению
DNS-имени между IP-адресами и именами хоста и функции. Требования для резолюции имени
определены в главе 4.7.
Примечание 2. Определения функционального адреса не рассматриваются в этом стандарте.
4.5 Резервирование
4.5.1 Общие данные
В этой главе содержатся общие требования и определения метод резервирования сетей
Ethernet на подвижных составах железных дорог (ECN).
Кроме того, в этой главе также описаны резервирования, осуществляемые на сетевом уровне
и на уровне конечных устройств. Внедрение сети Ethernet на подвижных составах железных
дорог (ECN) должны выбрать способ резервирования для выполнения требовании
приложении.
Поддерживаемые случаи отказов и вопросы сравнения надежности и доступности описаны в
приложении A.
Примечание. Настоящий стандарт не рассматривает резервирование конечных устройств, но
преимущество резервирования конечных устройств описаны в приложении A.
21
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
4.5.2 Определения
4.5.2.1 Сетевой компонент
Сетевой компонент определяется как единица, пострадавшая от отказа компонентов, что
означает в этой главе стандарта, от активного компонента сетевого устройства, связи между
активными компонентами, либо связи для интерфейса конечных устройств. Пример сетевых
компонентов показан на рисунке 3.
Примечание. Активные компоненты сетевого устройства описаны в стандарте МЭК (IEC)
61375-1, 4.2.2 (Типы сетевых компонентов).
Примечание. Границы ячеек и линии выделенные жирной линией являются примерами
сетевых компонентов.
Рисунок 3 - Пример компонентов сети
4.5.2.2 Время восстановления
Когда схема восстановления управляется на сетевом уровне, она применяется в сетях Ethernet
на подвижных составах железных дорог (ECN); время восстановления сетевой функции ECN
в случае отказа, ожидается, что будет короче, чем время в течение которого операции состава,
могут поддерживаться без потери прикладных функций поездов.
Время восстановления в сетях Ethernet на подвижных составах железных дорог (ECN) должны
включать:
• время обнаружения сбоя,
• восстановление времени переключения (см. примечание),
• время для повторной конфигурации в ECN, если необходимо.
Примечание. Время переключения это функция переключения времени от компонента отказа
до другого компонента.
Время восстановления сети должна быть измерена в тесте соответствия.
4.5.3 Резервирование, осуществляемое на сетевом уровне
Резервирование осуществляется на уровне сети, принимая топологию сети, которая имеет
резерв, это метод восстановления функции сети в случае отказа сетевых компонентов.
Примеры сетей Ethernet на подвижных составах железных дорог (ECN) с типичными сетевыми
топологиями, приведены в главе 4.2.2.
Требования к резервированию, осуществляемому, на сетевом уровне следующие:
Когда схема резервирования применяется в сетях Ethernet на подвижных составах
железных дорог (ECN) , отказ одного сегмента компонента сети не прерывает остальную
часть сети от работы без разделения сети, так что приложение может поддерживать свою
22
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
функцию.
Когда сетевой компонент появляется поздно, либо сетевой компонент появляется снова
(перезагрузка), продолжительность времени потери связи, вызванная реконфигурацией
сети должна быть равна или меньше, чем требуемое значение времени восстановления.
Например, во избежание широковещательного шторма петля переадресации не должна
формироваться в любое время.
Протокол избыточности среды (MRP), определенный в стандарте МЭК (IEC) 62439 может
быть использован для управления кольцевой топологией. Протокол цепной топологии
описанный в Приложении D может быть использован для управления цепной топологией.
4.5.4 Резервирование осуществляемое на уровне конечных устройств
Критические конечные устройства доступа должны иметь резервирование управления на
уровне конечных устройств, имеющих избыточные связи к сети. Конечное устройство может
продолжать связь в случае отказа на одном из резервных каналов. Если резервные ссылки
подключены к нескольким коммутаторам состава, то устройство может продолжать связь в
случае выхода из строя коммутатора состава. Конечные устройства, как правило, имеют две
связи которые называют двойным подключением. Конечное устройство в двойном
подключении должны использовать отдельные физические сетевые интерфейсы и не должны
создавать петлю для ECN. Неуправляемые коммутаторы не должен использоваться, чтобы
повторять двойную схему подключения. Пример использования двойного подключения
показан на рисунке 4.
Примером использования двойного подключения является то, пакеты дублированы и посланы
из обоих интерфейсов. При получении пакетов устройство принимает пакет, который получен
сначала и отказывается от другого.. Для идентифицирования дублированных пакетов,
имеются поле номера последовательности в сообщениях. В случае использования этого
метода, нарушение связи не произойдет в случае сбоя.
Также возможно, что одна из резервных каналов конечного устройства используется, а другая
связь принимается в случае отказа линии связи. В этом случае переключения между
резервными соединениями могут быть признаны в качестве переключения между резервными
устройствами от других устройств. В случае использования этого метода, нарушение связи
может происходить в случае отказа.
1) Двойное подключение (dual homing) в параллельных сетях
2) Двойное подключение (dual homing) в кольцевой топологии
3) Двойное подключение (dual homing) в цепной топологии
Рисунок 4 - Примеры двойного подключения
4.6 Качество обслуживания (Qos)
4.6.1 Общие данные
ECN должны быть в состоянии обеспечить кaчество
23
обслуживания QoS посредством
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
приоритезации трафика, когда это необходимо с требованиями приложения.
Качество обслуживания состоящее из коммутаторов состава, конечных устройств может
назначить приоритеты для пакетов, которые передает конечное устройства, если это
необходимо.
Примечание. Назначение приоритетов в пакетах коммутаторов состава, не запрещено,
например, в соответствии с портами, протоколами и адресами.
4.6.2 Уровень приоритета
Согласно стандарту IEEE 802.1D есть 8 уровней приоритета, самый высокий уровень
приоритета 7, а самый низкий уровень приоритета 0. Уровень приоритета по умолчанию 0.
Коммутаторы состава минимум должны поддерживать 2 очереди приоритетов, когда
обеспечивается качество обслуживания QoS. Когда поддерживается 2 очередь приоритетов,
уровни приоритета от 0 до 3 и от 4 до 7 соответственно могут быть сгруппированы. Когда
поддерживается 4 очередь приоритетов, уровни приоритета от 0 до 1, от 2 до 3, от 4 до 5, и 6
до 7 соответственно могут быть сгруппированы.
Отображение уровня приоритета для типа данных определяется в соответствии с
требованиями приложений, используемых в ECN, поскольку типы данных, которые будут
использоваться, и их рабочие параметры зависят от приложений. Таблица 7 показывает
сопоставление по умолчанию приоритетов для каждого типа данных в случае четырех
приоритетов.
В случае связи через ETB, уровень приоритета пакета должен соответствовать стандарту IEC
(МЭК) 61375-2-5.
Таблица 7 - Отображение приоритетов типа данных
Приоритет
Уровень
приоритета в
двоичной системе
Наивысший
2--й самый высокий
3-й самый высокий
cамая низкая
умолчанию)
(X: переменная)
11Х
10Х
01Х
(по 00Х
Тип класса
Требование
(М: Обязательно
R: Рекомендуется)
Данные по контролю
Данные обработки
Данные о сообщении
и данные потока
Данные
максимального
усилия
M
R
R
M
Примечание 1. Приоритеты для данные обработки, данных о сообщении и данных потока
определены в IEC (МЭК) 61375-2-3.
Примечание 2. Если пропускная способность типа данных с более высокими приоритетами не
ограничивается, более низкие приоритетные данные не могут иметь никаких шансов чтобы
быть передаными.
4.6.3 Назначение уровня приоритета
24
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Когда конечное устройство назначает приоритеты для отправки пакетов, конечное устройство
должно использовать область DSCP в IP-дейтаграмме, как определено в стандарте RFC2474.
Конечное устройство может использовать приоритеты кодовой точки помеченные в кадре
МАС.
Двоичное представление поля DSCP должно быть следующим.
LLL000
где
LLL: уровень приоритета (0-7) определенный в главе 4.6.2
4.6.4 Поведение коммутатора состава
Когда коммутатор состава поддерживает качество обслуживания, то коммутатор состава
должен быть в состоянии для обеспечения требуемой очередности передачи пакетов данных
в коммутаторе, как определено в IEEE 802.1D.
Когда коммутатор состава поддерживает качество обслуживания, коммутатор должен
соблюдать строгий приоритет, переключения на основе всех приоритетных очередей; т.е.
предполагают передачу трафика строго в соответствии с приоритетом выходных очередей.
Пакеты, находящиеся в очереди с высоким приоритетом, обрабатываются первыми. Пакеты
из следующей по приоритету обслуживания очереди начнут передаваться только после того,
как опустеет высокоприоритетная очередь
4.6.5 Ограничение скорости
Ограничение скорости является необязательным признаком коммутатора состава.
Коммутатор состава обеспечивает возможность ограничивать скорость кадров от конечных
устройств или от магистральных поездных узелов (TBN).
Если кадры должны быть отброшены, чтобы сохранить ограничение скорости, то кадры с
низким приоритетом должны быть отброшены в первую очередь.
Примечание. Ограничение скорости предотвращает сеть ECN от неожиданного поступления
кадрами, например поступающих от одного неисправногоконечного устройства.
4.6.6 Формирование уровня выхода
Формирование уровня выхода - дополнительная функция коммутатора состава. Коммутатор
состава обеспечивает возможность ограничить уровень структур выхода от конечных
устройств или от магистральных поездных узелов (TBN).
Если требуется отказаться от кадров, чтобы поддержать ограничение скорости, сначала
отказываются от низких приоритетных кадров.
4.7 IP-адрес и соответствующие определения
4.7.1 Сетевой адрес состава
25
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Каждое устройство связи, которое поддерживает IP коммуникации и подключен к сети
Ethernet для железнодорожных составов (ECN) должен иметь один или несколько IP-адресов,
как сетевые адреса состава. Сетевые адреса состава должны быть уникальными в пределах
сети состава.
Примечание. Устройства связи, подключенные к различным сетям состава могут иметь
одинаковые или разные сетевые адреса состава.
Состоят сетевой адрес должен использовать IPv4 личное пространство адресов,
определенных в IETF RFC1918, класс А личным адресом должен быть использован.
Сетевые адреса состава должны использовать IPv4 адреса описанные в спецификации IETF
RFC1918,
личным адрес класса А должен быть использован.
Когда
– Класс А используемый личный адрес
– сеть Ethernet для железнодорожных составов (ECN) соединяется к хребтовой сети поезда
(ETB)
– Сетевой адрес состава не совпадает с поездной сетью, адреса от 10.0.0.0 до 10.127.255.255
(10.0/9) должны быть использованы. Двоичное представление должно быть следующим
00001010.0ddddddd.dddddddd.dddddddd / 9
Где: Обозначение Описание
[d]
Это поле свободно используется для идентификации хоста в ECN. Это поле
может быть разделено, например
- сеть Ethernet для железнодорожных составов (ECN) делится на подсети,
- использование одинаковых значении сетевого адреса поезда в трех самых
значащих битах для идентификации нескольких ECN либо,
- использование только нижих 14 битов для преобразования сетевых адресов
NAT. (R-NAT в Приложении B один из примеров)
Примечание При использовании R-NAT, устройства имеют IP-адрес
рационально только с 14 битами. В пределах детерминированного
фиксированного электропоезда этот метод полезен для объединения без
беспорядка. Этот метод также вносит предварительно фиксированное
назначение IP-адреса конечных устройств.
14 нижних битов: r.ccccc.eeeeeeeer: Резервирование / идентификатор подсети
0 / 1с: номер транспорта от 1 до 31 (достаточное количество для обозначения
электропоезда) е: идентификатор конечного устройства от 1 до 255
(достаточное количество транспорта)
Это подсеть (10.0/9) применяется в сети Ethernet для железнодорожных составов (ECN)
называется локальной подсетью сети Ethernet (ECN).
26
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
4.7.2 Сетевой адрес поезда
Широкая адресация устройств связи поезда возможна с сетевым адресом поезда , который
является уникальным в поезде, если сеть Ethernet для железнодорожных составов (ECN)
подключена к хребтовой сети поезда (ETB). Сетевой адрес поезда может меняться с
внедрением каждым поезда. Для всех устройств связи, не обязательно иметь широкую
адресацию поезда, для многих из них достаточно и локального адреса ECN. сетевые адреса
поезда это адреса источника и назначения в сообщении на хребтовой сети поезда (ETB).
Сетевой адрес поезда и сетевой адрес состава может быть идентичным.
Если сетевой адрес поезда не совпадает с сетевым адресом состава, то сеть Ethernet для
железнодорожных составов (ECN) должна оказать по поддержку, для отображения сетевого
адреса поезда сетевому адресу состава. Адреса, которые не соответствуют спецификациям
сетевого адреса поезда не будут использоваться в качестве источника или для назначения
адресов в ETB, как определено в стандарте (IEC) МЭК 61375-2-5.
Примечание. Преобразования сетевых адресов (NAT) и шлюз прикладного уровня (ALG),
включая прокси являются типичными услугами отображения адресов.
Сетевой адрес поезда должен использовать личный IPv4-адрес, определенный в стандарте
IETF RFC 1918 и следовать определению согласно стандарту МЭК (IEC) 61375-2-5. Двоичное
представление сетевого адреса поезда должен быть следующим.
00001010.1bbxssss.sshhhhhh.hhhhhhhh / 18
Где:
Обозначение Описание
[b]
Идентификатор хребтовой сети поезда (ETB), который подключается к сети
Ethernet для железнодорожных составов (ECN)
[x]
Резерв. Должен быть 0
[s]
Идентификация состава сети, назначается в соответствии с результатами
внедрения. Значение 0 зарезервировано для подсети магистральной поезда
[h]
Уникальный идентификационный хост внутри сети Ethernet для
железнодорожных составов (ECN), составляет до 16382 хостов cостава.
Некоторые старшие биты могут быть использованы для определения
внутренней локальной подсети. В этом случае, маски сети (на стороне ECN)
должны принять во внимание эту декомпозицию. (должен быть продлен).
4.7.3 Адрес группы
Устройства связи могут быть сгруппированы на уровне состава или уровне поезда. Устройства
связи могут принадлежать нескольким группам. На уровне состава все члены группы
принадлежат одной сети. Адрес группы состава, назначенный для группы, должен быть
уникальным в пределах сети состава. Членство в группах состава как правило постоянно. На
уровне железнодорожного поезда все члены группы принадлежат к одной или нескольким
сетям состава. Адреса группы поезда, назначенные для группы должны быть уникальными в
27
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
пределах поезда. Членство в поездных группах может меняться с внедрением каждого поезда.
Адрес группы это IP-адрес многоадресной рассылки который определяется в стандарте IETF
RFC 2365.
В случае, если сеть Ethernet (ECN) подсоединяется к хребтовой сети поезда (ETB), IP-адрес
многоадресной рассылки на уровне сети Ethernet для железнодорожных составов (ECN) будет
239.255.0.0/16 (локальный объем определен в стандарте RFC 2365).
IP-адрес группы многоадресной рассылки на уровне поезда 239.192.0.0/14 (организационный
объем определен в стандарте RFC 2365), определен в стандарте МЭК (IEC) 61375-2-5.
Магистральный поездной узел (TBN) не направляет IP многоадресной датаграммы к
хребтовой сети поезда (ETB) если адрес назначения является IP-адресом многоадресной
рассылки на уровне сети Ethernet для железнодорожных составов (ECN).
4.7.4 Разрешение имени и определение имени
4.7.4.1 Разрешение имени
Резолюция имени для сетевого адреса состава и сетевого адреса поезда должны быть внедрены
локальной базой данных в коммуникационном устройстве или через систему доменных имён
DNS.
Сеть Ethernet для железнодорожных составов (ECN) должна обеспечивать функцию сервера
DNS. Местоположение сервера зависит от установки; серверы могут устанавливаться на
любых конечных и сетевых устройствах в сети ECN или на магистральных поездных узелах
(TBN) к которым присоединен ECN. В случае, если сеть Ethernet (ECN) подсоединяется к
хребтовой сети поезда (ETB), рекомендуется, чтобы сервер устанавливался на магистральном
поездном узелаех TBN. Сервер DNS должен быть резервным.
Каждое коммуникационное устройство, которое может быть устройством назначения для
связи хребтовой сети поезда (ETB) должно быть адресуемым в пространстве доменных имен
поезда.
Примечание. Пространство доменного имени поезда определяется как “ltrain” например,
согласно стандарту МЭК (IEC) 61375-2-5
4.7.4.2 Самоидентификация конечного устройства
Для самостоятельной адресации конечного устройства внутренний хост должн быть объявлен
как: "локальный" 127.0.0.1
4.7.4.3 Конечное устройство локальной идентификации
По умолчанию, все хосты объявлены в "lcst" домене, которые локальны для каждой сети
ECN.
Пример "mpu" или "mpu.lcst." cвязаны с тем же локальным конечным устройством c “mpu"
IP-адресом.
28
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
4.8 IP-адрес и управление конфигурацией сети
4.8.1 Управление сетевым адресом состава
Сетевой адрес состава в устройстве можно настроить статически или динамически.
Протокол динамической конфигурации сетевого узла (DHCP) должен быть использован,
когда сетевой адрес состава настроен динамически.
При использовании протокола динамической конфигурации сетевого узла (DHCP) сеть
Ethernet состава предоставляет функцию сервера протокола динамической конфигурации
сетевого узла (DHCP). Местонахождение сервера зависит от внедрения; серверы могут быть
внедрены на любых конечных устройствах и сетевых устройствах в сетях Ethernet состава или
на магистральный поездной узел (TBN) который прилагается к сети Ethernet состава. В случае,
когда сеть Ethernet состава прикреплен к хребтовой сети поезда (ETB) рекомендуется внедрить
в магистральный поездной узел (TBN). Сервер протокола динамической конфигурации
сетевого узла (DHCP) должен быть избыточным.
4.8.2 Управление сетевым адресом поезда
Когда IP-адрес сети поезда присваивается к устройству, то устройство может либо не может
настроить сетевой адрес поезда к его Ethernet порту.
Магистральный поездной узел (TBN) в качестве маршрутизатора должен поддерживать
преобразование сетевых адресов (NAT) для отображения сетевого адреса поезда в сетевых
адресах состава для устройств, которые не настроены в сетевых адресах поезда на
собственных интерфейсах Ethernet. Преобразование сетевых адресов поездов (R-NAT)
определенное в Приложении B может быть использован для упрощения адреса алгоритма
перевода в магистральных поездных узлах (TBN).
Преобразование сетевых адресов (NAT) может вызвать проблемы для конкретных
протоколов, например, необходимость замены адреса в полезную нагрузку IP-дейтаграмм,
расширенное преобразование сетевых адресов (NAT) в решении проблем следует
использовать для конкретных протоколов. В противном случае, конечные устройства, которые
адресуются по сетевым адресам поездов должны иметь функцию IP-псевдоним; т.е. два
разных IP-адреса могут быть настроены на один интерфейс Ethernet. Локальные адреса сети
Ethernet состава (ECN) используется для локальной связи в сети Ethernet состава (ECN), и
сетевые адреса поезда используются для связи по хребтовой сети поезда (ETB).
Магистральный поездной узел (TBN) сможем направить дейтаграмму IP по адресу
назначения, что является сетевым адресом.
После нового открытия, обновление сетевого адреса поезда является обязательным. Это
применяется для подготовки сетевых адресов, управляемых на каждое устройство связи и
сетевых адресов поезда, управляемых в различных услугах, включая маршрутизацию,
преобразования сетевых адресов (NAT), сервера динамической конфигурации сетевого узла
(DHCP), и сервера системы доменных имён.
В случае, когда сетевые адреса управляются конечными устройствами с динамической
конфигурацией сетевого узла (DHCP) клиентом, конечные устройства и сервера
динамической конфигурации сетевого узла (DHCP) должны поддерживать динамическую
конфигурацию сетевого узла (DHCP) сообщая силы замены, определенное в запросах на
комментарии 3203. инженерного совета Интернета. Сервер динамической конфигурации
сетевого узла (DHCP) должны отправить сообщение силы замены клиентам динамической
29
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
конфигурации сетевого узла (DHCP) сетевым адресом поезда после инаугурации, и клиенты
сервера динамической конфигурации сетевого узла (DHCP) обновят сетевые адреса поезда на
получение сообщения силы замены.
ПРИМЕЧАНИЕ: возникновение инаугурации ограничивается вводом в эксплуатацию
инициализации, соединящая и разъединяющая время. Потеря или нахождение
маршрутизатора на уровне поезда не всегда является как следствие новой инаугурации.
Решение изменения IP-адреса поезда всегда находится под признанной ответственностью
приложения поезда. См МЭК (IEC) 61375-2-5.
4.8.3 Статические параметры конфигурации сети
Таблица 8 показывает параметры конфигурации сети для конечных устройств, когда
используются статические параметры конфигурации сети.
Таблица 8 - Конечные статические параметры конфигурации сети
(О: Обязательное У: Условное, Д: Дополнительное)
Параметр
Наименование хоста
Доменное
умолчанию
имя
Тип
О
по У
IPv4-адрес
IPv4 адрес маски
Адрес сервера системы
доменных имён (DNS) IPv4
IPv4 маршрут по умолчанию
О
О
У
IPv4 статический маршрут
Д
Д
Описание
Наименование хоста должно быть уникальным в
ECN.
Это является обязательным при использовании имен
системы доменных имён (DNS). Для определения
доменного имени, см 4.7.4.
Для определения сетевого адреса, см 4.7
Для определения сетевого адреса, см 4.7
Это является обязательным при использовании имен
системы доменных имён (DNS).
Магистральный поездной узел (TBN) типичного
шлюза по умолчанию.
Может быть использован для доступа к
определенным устройств и подсетей.
4.8.4 Параметры конфигурации протокола динамической конфигурации сетевого
узла (DHCP)
Таблица 9 показывает, требования к опции протокола динамической конфигурации
сетевого узла (DHCP), что является поддержкой при использовании протокола динамической
конфигурации сетевого узла (DHCP).
Тавлица 9 - Опции протокола динамической конфигурации сетевого узла (DHCP)
(О: Обязательное У: Условное, Д: Дополнительное)
Номер
опции
1
3
Требования Наименование
Описание
О
О
6
У
IPv4 адрес маски
Список IPv4 маршрутизаторов доступны на
подсети
Список адресов серверов DNS.
Маска подсети
Опция
маршрутизатора
Доменное
имя
опции сервера.
30
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
12
Д
28
Д
42
У
протокол
синхронизации
времени по сети
серверов опции
43
Д
Производитель
конкретной
информации.
51
О
53
О
54
О
55
О
56
Д
IP-адрес
время
аренды
DHCP-тип
сообщения
Идентификатор
сервера
Список
параметров
запроса
Сообщение
61
Д
Клиентидентификатор
Информационный
параметр агента
ретрансляции
ПРИМЕЧАНИЕ: Для того, чтобы сохранить всегда один и тот же IP-адрес из DHCP-сервера,
в зависимости от местоположения или типа устройства конечных устройств, конечное
устройство посылает DHCP опции 61 (клиент-идентификатор) или коммутатор состоит, где
конец устройство подключено вставок DHCP опции 82 определяется в IETF RFC 3046.
82
Д
Доменное
имя
опции
Трансляционный
адрес опции
Это является обязательным для конечных
устройств при использовании имен системs
доменных имён (DNS)
Имя
клиента
протокола
динамической
конфигурации сетевого узла (DHCP)
Трансляционный адрес используется на подсети
протокола
динамической
конфигурации
сетевого узла (DHCP) клиентов
Список
адресов
серверов
протокол
синхронизации времени по сети (NTP).
Это является обязательным для конечных
устройств, при использовании протокола
синхронизации времени по сети (NTP) или
упрощённого
протокола
синхронизации
времени по компьютерной сети (SNTP)
Это используется для обмена поставщика
конкретной информации между серверами и
клиентами.
Эта опция может быть поддержано.
Допустимое время аренды для назначенного IPадреса
Должен быть использован для идентификации
типа DHCP сообщения
Эта опция используется для идентификации
адреса DHCP-сервера.
Может быть использован для DHCP клиента,
чтобы запросить конкретные параметры
конфигурации.
Эта опция используется для отправки
сообщения об ошибке из сервера DHCP для
клиентов
DHCP.
DHCP-клиент
может
использовать этот параметр, чтобы указать на
причину снижения предложения.
DHCP-клиент
заполняет
уникальный
идентификатор.
Эта опция может быть использована, чтобы
сохранить тот же IP-адрес для клиента DHCP,
см. Примечание
Эта опция может быть использована, чтобы
указать местоположение клиента DHCP.
4.8.5 IP-адрес управления для резервирования магистрального поездного узла (TBN).
Чтобы управлять избыточностью хребтовым подключением поезда внутри сети Ethernet
вагона (ECN), сеть Ethernet вагона (ECN) может быть связано более чем с одним
магистральным поездным узлом (TBN) к поездной связи.
31
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Резервирование магистрального поездного узла (TBN) управляется в соответствии с WTB
или ETB. Когда избыточная группа TBN реализуется и данная группа является
маршрутизатором между ECN и поездной связью, избыточная группа TBN должна
экспортировать общий сетевой адрес состава для службы маршрутизации на ECN стороне.
Когда новый TBN избирается в качестве активного маршрутизатора, то TBN направляет
безвозмездной ARP к ECN для того, чтобы обновить таблицы ARP в приемных устройств.
4.9 Интерфейс сетевого устройства
4.9.1 Общие данные
В подразделе 4.9 определяет интерфейсы для сетевых устройств; то есть репитеры, сетевые
коммутаторы и маршрутизаторы. Коммутатор состава и маршрутизатор могут выступать в
качестве конечных устройств; в этом случае они также должны соответствовать интерфейсам
конечных устройств в сети слоя и других верхних слоев, определенных в 4.10. Есть два класса
коммутаторов состава, как определено в 4.2.4; неуправляемый коммутатор состава и
управляемый коммутатор состава. Управляемый коммутатор состава должен поддерживать
все требования к неуправляемыму сетевому коммутатору.
4.9.2 Функциональные требования
Таблица 10 показывает сводку интерфейсов сетевых коммутаторов; подробности описаны
в следующих подразделах.
Таблица 10 - сводка интерфейсов сетевых коммутаторов
Статус в (M: Обязательное, O: Дополнительное, C: Условное, -: Не доступны или не
требуются)
Уровни
Требования
Физичес Функция
кий
автопереговоро
уровень в
MDI/MDI-X
перекрестное
соединение
Класс D
(Категория 5e),
экранированны
й STP кабель с
2 витыми
парами
Класс D
(Категория 5e),
Повторит
ель
Статус
Неуправляе Управляе
мый
мый
коммутатор коммутато
состава
р состава
Роутер
-
O
O
O
O
O
O
O
Ссылки и
примечания
IEEE 802.3
ISO/IEC 11801
IEC 61156-6
O
O
O
O
O
O
O
O
Для 100BASETX и 10BASE-T
ISO/IEC 11801
IEC 61156-6
32
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
неэкранирован
ный STP
кабель с 2
витыми парами
Для 100BASETX и 10BASE-T
M12 Dкодированный
разъем (гнездо)
IEC 61076-2-101
C
C
C
C
Для 100BASETX и 10BASE-T
-
M
M
M
IEEE 802.3
Управление
потоком
-
O
O
_
IEEE 802.3
Ретрансляция
кадров
-
M
M
_
IEEE 802.1D
Фильтрация
кадров
-
M
M
_
IEEE 802.1D
VLAN сервисы
-
M
M
_
IEEE 802.1Q
-
M
M
_
IEEE 802.1D
-
M
M
_
IEEE 802.1D
-
-
M
_
IEEE 802.1D
Ограничение
скорости
-
O
O
_
Формирование
уровня выхода
-
O
O
_
Зеркалировани
е порта
-
O
O
_
-
-
M
M
Кабельн MAC cервисы с
ый
основным/
уровень отмеченным
MAC-кадром
Кадр
организации
очереди
Отмеченный/не
отмеченный
кадр
Управление и
дистанционное
управление
Cетевой
уровень
33
четвёртая
версия
интернет
протокола (IP)
IETF RFC 791
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
переадресация
IPv4
-
-
-
M
-
-
M
M
IETF RFC 792
-
-
M
M
IETF RFC 826
-
-
M
M
IETF RFC 768
-
-
M
M
IETF RFC 793
IGMP версия
2/3 (роутер)
-
-
-
O
IETF RFC
2236,3376
IGMP версия 2
(хост)
-
-
M
O
IETF RFC 2236
IGMP версия 3
(хост)
-
-
O
O
IETF RFC 3376
IGMP
отслеживание
-
-
M
-
IETF RFC 4541
-
-
C
C
IETF RFC 2131
DHCP
ретранслятор
- опция
информация
-
-
O
-
IETF RFC 3046
DHCP (сервер)
-
-
O
O
IETF RFC 2131
C
IETF RFC
1034,1035
протокол управ
ляющих сообщ
ений
Интернета
ICMP
ARP
Транспо UDP
ртный
уровень TCP
Прикла
дной
уровень
DHCP (клиент)
DNS (клиент)
-
-
C
DNS (сервер)
-
-
O
O
IETF RFC
1034,1035
SNTP (клиент)
-
-
O
O
IETF RFC 1361
NTP версия 3
(клиент)
-
-
O
O
IETF RFC 1305
4.9.3 Требования к эффективности
34
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Сетевой коммутатор должен поддерживать при минимальных очередей 2 приоритета, как
определено в 4.6.2.
Сетевой коммутатор должен поддерживать строгое переключение приоритета на основе
всех приоритетных очередей, как определено в 4.6.4.
4.9.4 Физический уровень
4.9.4.1 Протоколы
4.9.4.1.1 Интерфейс сетевого устройства для конечных устройств
Интерфейс сетевого устройства для подключения конечных устройств должен
поддерживать 100BASE-TX и 10BASE-T, к примеру может дополнительно поддерживать в
целях повышения электрической прочности и электромагнитной неприкосновенной
совместимости.
• 100BASE-TX Физический уровень
- Подуровень физического кодирования (PCS) и подуровень подключения к физической
среде (РМА), 100BASE-X, определен в IEEE 802.3
- Подуровень зависящий от физической среды (PMD) и полосы среднего типа, 100BASE
TX, определены в IEEE 802.3
• 10BASE-T физический уровень
- Витая пара блока подключения к среде (МАU) и полосы среднего типа, 10BASE-T,
определяется в IEEE 802.3
Полный дуплексный режим, который определен в IEEE 802.3, поддерживается во
избежание столкновения.
Авто переговорная функция, которая определена в IEEE 802.3, должна быть в состоянии
поддерживания для подключения временных конечных устройств. Не рекомендуется
использовать для подключения стандартных конечных устройств во избежание связи с
непреднамеренной скоростью или установленного дуплексного режима.
Автоматическая функция кроссовера MDI / MDI-X, которая автоматически настраивает
MDI или MDI-X, могут не поддерживаться.
Авто полярная функцию не рекомендуется использовать из-за конкретного решения.
Сила энергетического оборудования (PSE) питания через Ethernet (PoE), который
определен в IEEE 802.3, могут не поддерживаться.
4.9.4.1.2 Интерфейс сетевого устройства для других сетевых устройств
Интерфейс сетевого устройства для подключения других сетевых устройств должны
поддерживать физический уровень, определенный в IEEE 802.3, когда дополнительный
трансивер с усиленным сигналом не применяется.
100BASE-TX является предпочтительным, но 10BASE-T может быть дополнительно
поддерживается с целью повышения электрической прочности и к примеру электромагнитной
неприкосновенной совместимости.
В целях повышения помехоустойчивости далее, трансивер с усиленным сигналом может
соединиться к 100BASE-TX PMD или 10BASE-T МАУ, который определен в Приложении С.
1000BASE или интерфейс выше может быть использован для того, чтобы поддержать более
высокую пропускную способность.
Полный дуплексный режим, который определен в IEEE 802.3, поддерживается во
избежание столкновения.
Функция автоматического согласования, которая определена в IEEE 802.3, не
рекомендуется использовать во избежание связи с непреднамеренной скоростью или
установленного дуплексного режима.
Автоматическая функция кроссовера MDI / MDI-X, которая автоматически настраивает
MDI или MDI-X, могут не поддерживаться.
Авто полярную фунцию не рекомендуется использовать из-за конкретного решения.
35
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
4.9.4.2 Кабели
Этот пункт применяется, когда используется 100BASE-TX или 10BASE-T.
Кабели должны соответствовать ISO / IEC 11801 и IEC 61156-6. Класс D (категории 5e) с
поддержкой двумя витыми парами.
Необходимо использовать кабель с экранированной витой парой (STP) и
неэкранированную витую пару (UTP).
Кабельный датчик рекомендованный для подключения внутри автомобиля составляет 0,5
мм2 (AWG20), 0,34 мм2 (AWG22) или 0,25 мм2 (AWG24).
Кабельный датчик рекомендованный для подключения между автомобиля составляет 0,5
мм2 (AWG20), или выше поверхности.
4.9.4.3 Разъемы
4.9.4.3.1 Интерфейс сетевого устройства для конечных устройств
Этот пункт определяет требования к разъемам, используемых для подключения конечных
устройств. Также применяется, когда используется 100BASE-TX или 10BASE-T.
M12 D-кодированный разъем (гнездо), определенный в МЭК 61076-2-101, поддерживается
со стороны сетевых устройств. В этом случае M12 D-кодированный штекер должен быть
использован на кабельной стороне.
МЭК 61076-3-104 разъем (розетка) может быть использован на стороне сетевого
устройства. В этом случае, МЭК 61076-3-104 разъем должен быть использован на кабельной
стороне.
Разъем RJ45, определены в TIA / EIA-568-B, могут быть использованы для подключения
временных конечных устройств на стороне сети устройств. В этом случае разъем RJ45 должен
быть использован на кабельной стороне.
Картина 5 иллюстрирует разъемы. Закрепление за разъем M12 будет как показано в таблице
11.
Рисунок 5 - Д-кодом штекер M12
Таблица 11 - Закрепление за D-кодированный разъем M12
Ось
1
2
3
4
связь
TD+
RD+
TDRD-
4.9.4.3.2 Интерфейс сетевого устройства для других сетевых устройств
Этот пункт определяет требования к разъемам, используемых для подключения сетевых
устройств.
36
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Также применяется, когда используется 100BASE-TX или 10BASE-T.
М12 D-кодированный разъем (гнездо), определенный в МЭК 61076-2-101, поддерживается
на стороне сетевого устройства. М12 D-кодированный штекер должен быть использован на
кабельной стороне.
4.9.4.4 Экранирование и заземление понятия
4.9.4.4.1 Понятия внутреннего экранирования машины
Внутри машины, все экраны кабелей должны быть переданы и соединены с механической
землей машины. Для предотвращения влияния электромагнитной совместимости, кабель щит
должен быть подключен на 360 ° круговой основе в разъеме.
4.9.4.4.2 Понятия внутреннего экранирования машины
Два случая применения должны быть рассмотрены:
- Две соседние машины с одинаковыми потенциалами
- Две соседние машины с разными потенциалами
Когда две смежных машины с одинаковыми потенциалами, то кабель Ethernet щит должен
иметь непрерывность и нет необходимости в прерывание экранирования.
Когда две соседние автомобили на различных потенциалах, то кабель Ethernet должен быть
прерван, чтобы избежать заземления тока, протекающего между автомобилями.
4.9.5 Канальный уровень
4.9.5.1 Коммутатор состава
Обязательные требования для коммутаторов состава определяются в следующем.
Услуги MAC поддерживаются основным (без тегов) и помеченным кадром, который
определен в IEEE 802.3.
Ретрансляция кадров должны быть поддержаны, которые определены в IEEE 802.1D.
Ретрансляция кадров обеспечивают прием кадра, передачи кадра, и экспедицию кадра.
Фильтрация кадров, которые определены в IEEE 802.1D, должны быть поддержаны.
Фильтрация кадров обеспечивает обучение адресов и фильтрации данных.
Служба VLAN, которая определена в IEEE 802.1Q, должна быть поддержана коммутатором
состава.
Рамка очереди, которая определена в IEEE 802.1D, должны быть поддержаны
коммутатором состава.
Очереди кадров может обрабатывать несколько классов данных во время ретрансляции
кадра для достижения качества услуги.
ПРИМЕЧАНИЕ Когда кадр поддерживается очередью, коммутатор состава читает поле
DSCP, как определено в 4.6.
Рамки, помеченные и непомеченные, которые определены IEEE 802.1Q, должны быть
поддержаны коммутатором состава. Рамку с пометкой можно вставить в рамку в основной
(без тегов) рамы для входных портов и рама без пометки может удалить пометку из помеченых
рамки для выходного порта.
Обязательные требования только для управляемых коммутаторов состава определяются в
следующем.
Управление и дистанционное управление, которые определены в IEEE 802.1D, должны
поддерживаться управляемыми коммутаторами состава.
Дополнительные требования к коммутаторам состава определяется в следующем.
Управление потока должны быть поддержаны, которые определяются как операция PAUSE
MAC-управления в IEEE 802.3. Управление потоком обеспечивает способность ингибировать
передачу кадров.
Поддерживаются ограничение скорости и выход скорости формирования , которые
определены в 4.6.5 и 4.6.6.
37
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Зеркалирование портов, которое настраивает один или несколько портов, поддерживается
для отражения движения от другого порта (ов).
4.9.5.2 Маршрутизатор
Маршрутизаторы должны поддерживать требования канального уровня к конечному
устройству, см 4.10.
4.9.6 Сетевой уровень
Управляемые коммутаторы состава и маршрутизаторы должны поддерживать требования
уровня сети к конечным устройствам, см 4.10.
Маршрутизаторы должны дополнительно поддерживать IP (Version4) пересылку.
4.9.7 Транспортный уровень
Управляемый коммутаторы состава и маршрутизаторы должны поддерживать требования
транспортного уровня к конечным устройствам, см 4.10.
Маршрутизаторы должны поддерживать IGMP версии 2 требования маршрутизатора,
определенные в RFC 2236 IETF, также могут поддерживать IGMP версии 3 требования
маршрутизатора, определенные в RFC 3376 IETF.
Управляемые коммутаторы состава должны поддерживать IGMP версии 2 требования
хозяев, также могут поддерживать IGMP версии 3 требования хозяев.
ПРИМЕЧАНИЕ IGMP версии 3 совместим с IGMP версии 2 и версии 1. IGMP версии 3
дополнительно поддерживает фильтрацию источника.
Выслеживающий IGMP, который определен в RFC 4541 IETF, поддерживается
управляемыми коммутаторами состава. Выслеживающий IGMP фильтры многоадресной
рамы, предназначенные для переключения портов, у которых нет членов группы
многоадресной передачи соединяются.
4.9.8 Применение уровня
Управляемые коммутаторы состава и маршрутизаторы должны поддерживать требования
уровня к конечным устройствам, см 4.10
DHCP информационный параметр агента ретрансляции, который определен в RFC 3046 IETF,
может быть поддержан управляемыми коммутаторами состава. Коммутаторы состава могут
выступать в качестве агентов ретрансляции для того, чтобы назначить конкретные IP-адреса в
соответствии с информацией, вставленной в коммутаторах состава.
4.10 Интерфейс конечного устройства
4.10.1 Общие данные
Подпункт 4.10 определяет интерфейсы для конечных устройств.
Таблица 12 показывает сводку интерфейсов конечных устройств; детали указаны в
следующих подразделах. Есть четыре класса конечных устройств, как это определено в 4.2.3.
Таблица 12 - Сводная информация интерфейсов устройств конечных
Уровни
Требования
Физически 00BASE-TX
й уровень
10BASE-T
Полный
дуплексный
режим
Функция
Временн
ый
Статус
Местный Поездн
состав
ая связь
Топологи
я поезда
Ссылки и
примечания
M
М
М
М
IEEE 802.3
O
O
O
O
IEEE 802.3
M
М
М
М
IEEE 802.3
M
O
O
O
IEEE 802.3
38
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
автопереговоров
MDI/MDI-X
перекрестное
соединение
O
O
O
O
O
O
IEEE 802.3
O
O
O
O
ISO/IEC 11801
IEC 61156-6
O
O
O
O
ISO/IEC 11801
IEC 61156-6
O
O
O
O
O
O
O
O
IEC 61076-3-104
O
O
O
O
TIA/EIA-568-B
M
М
М
М
IEEE 802.3
O
O
O
O
IEEE 802.1Q
IP v 4 четвёртая
версия интернет
протокола (IP)
ICMP
M
М
М
М
IETF RFC 791
M
М
М
М
IETF RFC 792
ARP
M
М
М
М
IETF RFC 826
UDP
M
М
М
М
IETF RFC 768
Технология
Power over
Ethernet (PoE)
Класс D
(Категория 5e),
экранированный
STP кабель с 2
витыми парами
Класс D
(Категория 5e),
неэкранированн
ый STP кабель с
2 витыми
парами
M12 Dкодированный
разъем (гнездо)
IEC 61076-3-104
гнездо (выход)
RJ45
соединитель
(гнездо)
MAC сервис с
основным MAC
кадром
Канальный
уровень
MAC сервис с
отмеченным
MAC кадром
Сетевой
уровень
39
O
O
IEC 61076-2-101
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Транспорт
ный
уровень
TCP
M
М
М
М
IETF RFC 793
IGMP версия 2/3
(хост)
O
O
O
O
IETF RFC 2236,
3376
DHCP (клиент)
O
O
С
С
IETF RFC 2131
DHCP (сервер)
O
O
O
O
IETF RFC 2131
DNS (клиент)
O
O
O
М
IETF RFC 1034,
1035
DNS (сервер)
O
O
O
O
IETF RFC 1034,
1035
O
O
O
O
IETF RFC 1361
O
O
O
O
IETF RFC 1305
NTP версия 3
(сервер)
O
O
O
O
IETF RFC 1305
SNMP версия 2
(агент)
O
O
O
O
IETF RFC 1901
Telnet или SSH
сервер
O
O
O
O
ETF RFC 854
IETF RFC 4251
Прикладно SNTP (клиент)
й уровень NTP версия 3
(клиент)
4.10.2 Физический уровень
4.10.2.1 Протоколы
Физический уровень должен соответствовать IEEE 802.3 стандарта. 100BASE-TX должны
поддерживаться и 10BASE-T можно использовать для того, чтобы увеличить к примеру,
надежность и неприкосновенность электромагнитной совместимости.
• 100BASE-TX Физический уровень
- Подуровень физического кодирования (PCS) и подуровень подключения к физической
среде (РМА), 100BASE-X, определен в IEEE 802.3
- Подуровень зависящий от физической среды (PMD) и полосы среднего типа, 100BASE
TX, определены в IEEE 802.3
• 10BASE-T физический уровень
- Витая пара блока подключения к среде (МАU) и полосы среднего типа, 10BASE-T,
определяется в IEEE 802.3
Полный дуплексный режим, который определен в IEEE 802.3, поддерживается во
избежание столкновения.
Авто переговорная функция, которая определена в IEEE 802.3, должна быть в состоянии
поддерживания для подключения временных конечных устройств. Не рекомендуется
использовать для подключения стандартных конечных устройств во избежание связи с
непреднамеренной скоростью или установленного дуплексного режима.
Автоматическая функция кроссовера MDI / MDI-X, которая автоматически настраивает
MDI или MDI-X, могут не поддерживаться.
Авто полярная функцию не рекомендуется использовать из-за конкретного решения.
40
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Сила энергетического оборудования (PSE) питания через Ethernet (PoE), который
определен в IEEE 802.3, могут не поддерживаться.
4.10.2.2 Кабели
Кабели должны соответствовать ISO / IEC 11801 и IEC 61156-6. Класс D (категории 5e)
поддерживается с двумя витыми парами.
Используется экранированная витая пара (STP) кабеля, также может быть использован
неэкранированная витая пара (UTP) кабеля.
Датчик кабеля рекомендуется использовать в 0,5 мм2 (AWG20), 0,34 мм2 (AWG22) или 0,25
мм2 (AWG24).
4.10.2.3 Разъемы
Для стандартного End Device M12 D-кодированный Разъем (гнездо), определенный в МЭК
61076-2-101, поддерживается со стороны сетевых устройств. В этом случае M12 Dкодированный штекер должен быть использован на кабельной стороне.
МЭК 61076-3-104 разъем (розетка) может быть использован на стороне конечного
устройства. В этом случае, МЭК 61076-3-104 разъем должен быть использован на кабельной
стороне.
Разъем RJ45, определены в TIA / EIA-568-B, могут быть использованы для подключения
временных конечных устройств на стороне сети устройств. В этом случае разъем RJ45 должен
быть использован на кабельной стороне.
Рисунок 5 в 4.9.4.3 иллюстрирует разъемы. Закрепление должно быть, как показано в
таблице 11.
4.10.2.4 Защитные и заземляющие понятия
Все экраны кабелей должны быть переданы и соединены с механической землей машины.
Для предотвращения влияния электромагнитной совместимости, кабель щит должен быть
подключен на 360 ° круговой основе в разъеме.
4.10.3 Канальный уровень
MAC в канальном уровне должен соответствовать стандарту IEEE 802.3.
Должны быть поддержаны услуги MAC с основной рамой, которые определены в IEEE
802.3.
Может быть поддержаны услуги MAC с помеченной рамой, которые определены в IEEE
802.1Q.
4.10.4 Сетевой уровень
Поддержка:
-IP-версия 4, которая определена в RFC 791 IETF.
-ICMP, который определен в RFC 792 IETF.
-ARP, которая определяется в IETF RFC 826.
ПРИМЕЧАНИЕ См 4.6 для установки значения DSCP по конечным устройствам.
4.10.5 Транспортный уровень
Поддержка:
-UDP, который определен в IETF RFC 768.
-TCP, который определен в IETF RFC 793.
-IGMP версии 2 требования хозяев.
-IGMP версии 3 требования хозяев.
4.10.6 Прикладной слой
Функция DHCP-клиент, которая определена в RFC 2131 IETF, могут не поддерживаться. В
случае, если поездная связь конечных устройств и железнодорожная топология конечных
устройств управляется на поезд сетевого адреса от себя, то DHCP должен быть поддержан.
Функция DNS-клиента, которая определяется в IETF RFC 1034, может быть
поддерживаться для отображения между IP-адресами и именами (например, имена хостов и
имена функций, представленных в FQDN). Железнодорожная топология конечных устройств
41
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
должна поддерживать функцию клиента DNS, чтобы решить железнодорожных маршрутов
адреса из имен хостов или имен функций; сетевой адрес поезда меняется инаугурацией.
Клиентская функция SNTP, которая определена в RFC 1361 IETF или NTP версии 3
функции клиента, который определен в IETF RFC 1305, может поддерживаться для
синхронизации времени. Когда NTP используется ECN предоставляет функцию сервера NTP.
Местонахождение сервера зависит от реализации, но рекомендуется, чтобы быть реализованы
в TBN.
Другие протоколы, такие как FTP, определенные в IETF RFC 959, HTTP определенные в
IETF RFC 2616, и TFTP определен в RFC 1350 IETF могут не поддерживаться.
SNMP версии 2 функция агента, который определен в IETF RFC 1901, 1905 и 1906, должны
быть поддержаны.
Сервер Telnet (IETF RFC 854) или сервер SSH (RFC 4251 IETF или другие) могут быть
реализованы для того, чтобы управлять конечными устройствами.
Примечание 1 Информация о железнодорожной топологии указаны в МЭК 61375-2-3 и /
или IEC 61375-2-4.
Примечание 2 Протоколы поставляющие данные процесса и сообщения данных,
определенный в МЭК 61375-2-3 могут быть использованы внутри ECN.
Примечание 3 Любые протоколы, поставляя данные процесса и сообщения данных могут
быть использованы внутри ECN.
4.11 Функции шлюза
4.11.1 Функции шлюза WTB
Функции шлюза между ECN и WTB должны быть реализованы в TBN, если TBN
подключен к WTB, определенной в МЭК 61375-2-1.
TBN между ECN и WTB реализован в виде шлюза прикладного уровня (ALG). 6
иллюстрирует логическую структуру TBN.
Рисунок 6 - Логическая структура шлюза между ECN и WTB
4.11.2 Функции шлюза ETB
Функции шлюза между ECN и ETB должны быть реализованы в TBN, если TBN подключен
к ETB, определенной в МЭК 61375-2-5.
TBN между ECN и ETB реализуется в качестве маршрутизатора и / или в качестве шлюза
прикладного уровня (ALG).
Если сетевой адрес поезда, назначенный устройству связи в ECN не совпадает с сетевым
адресом состава, то TBN должен поддерживать сервис, который отображает сетевой адрес
поезда к сетевому адресу состава, как определено в 4.7. Адреса, которые не соответствуют
спецификациям на сетевом адресе поезда не будут использоваться в качестве источника или
назначения адресов за пределами ECN. Трансляция сетевых адресов (NAT), определенный в
RFC 3022 IETF является реализацией при типичном отображении, осуществляется в функции
маршрутизации TBN. См 4.8.
Резервная пара TBN-ов разделяет IP-адрес на ECN стороны как адрес шлюза между ECN и
ETB. См 4.8.5.
4.12 Управление сетью
4.12.1 ECN управлениe сетью
Устройства связи в ECN должны поддерживать SNMP функцию агента для управления
сетью. SNMPv2 определенные в IETF RFC 1901 и 1905 1906 являются минимальными
требованиями.
42
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Стандарты MIB, определенные в RFC 1213 IETF должно быть поддержаны.
4.12.2 WTB управления сетью
Функция TNM для WTB должна быть реализована в TBN, если TBN подключен к WTB,
определенной в МЭК 61375-2-1.
Услуги по управлению сетью ECN, определенные в 4.12.1 должны быть доступны
функцией TNM для WTB.
4.12.3 ETB управление сетью
SNMP используется для управления устройствами связи на ETB, как определено в МЭК
61375-2-5.
SNMP агент услуг реализованный на устройствах связи в ECN должен быть доступен через
ETB.
5 Тест соответствия
Для утверждения на соответствие данной части стандарта, оборудование, как ожидается,
должно пройти ряд тестов. Оборудования для тестирования должны включать:
• Конечное устройство,
• Сетевое устройство, и
• TBN.
ПРИМЕЧАНИЕ TBN также соответствует IEC 61375-2-1 или IEC 61375-2-5.
План тестирования соответствия для ECN не в рамках этой части стандарта.
ПРИЛОЖЕНИЕ
(справочное)
Сравнение надежности и доступности между архитектурами ECN
А.1 Общие
Это приложение показывает надежность и доступность в различных архитектурах ECN,
чтобы помочь выбрать подходящий архитектуры ECN. Примеры толерантных (и
нетерпимости) случаях отказа типичных сетевых топологий описаны. Формулы надежности и
доступности рассчитаны, также описаны.
А.2 Случай отказов
А.2.1 Определения
Случай отказов определяется в качестве одного из вариантов компонентов в количестве
отказа и местоположения.
Термин отказ одного компонента сети означает состояние, в котором один из сетевых
компонентов перестает работать, как показано на рисунке А.1.
Термин отказ двух компонентов сети означает состояние, в котором два сетевых
компонента перестают работать в тот момент, как показано на рисунке А.2.
Примечание - компонент сети определяется в 4.5.2.1; активный компонент сетевого
устройства, ссылка между активными компонентами и конечными устройствами.
Примечание -1 Х, где неисправный компонент.
Примечание -2 Жирные линии и коробки, где компоненты сети.
43
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок А.1 - Пример отказа одного компонента сети
Примечание -1 Х, где неисправный компонент.
Примечание -2 Жирные линии и коробки, где компоненты сети.
Рисунок А.2 - Пример отказа двух компонента сети
В случае отказа (ов) компонента сети состояние сети можно изменить на один из
следующих состояний от нормального состояния, которых не имеет провал в сети.
- Неисправность. В этом состоянии сеть отделена.
- Частично функционированный штат. В этом состоянии сеть не разделена, но сеть не может
обеспечить те же услуги, что в нормальном состоянии.
- Полностью функционированный штат. В этом состоянии сеть может обеспечить те же
услуги, что в нормальном состоянии.
А.2.2 Пример в случаях отказа - Линейная топология
Линейная топология не выдерживает отказа одного компонента сети, как показано на
рисунке А.3.
Если функция байпаса применяется к каждому активному компоненту, как показано на
рисунке А.4, сеть частично функционируют в случае выхода из строя активного компонента;
т.е. сеть не разделена, но конечные устройства, подключенные к неисправным компонентам
не могут продолжать общаться.
Примечание активные компоненты сети с функцией байпаса эффективны, во избежание
разделения сети и могут быть применены к другим топологиям.
44
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок А.3 - Пример отказа одного компонента в ссылке на линейной топологии
Рисунок А.4 - Пример отказа одного компонента в качестве активного компонента на
линейной топологии
А.2.3 Пример случаев отказа - Параллельные сети
Отказ одного компонента на связи между активными компонентами не вызывает
неисправности сети, что показана на рисунке А.5.
В случае отказа одного из активных двухкомпонентной самонаведения конечных
устройств, которые имеют избыточные ссылки на нескольких активных компонентов
(коммутаторы сети) могут продолжать общаться; Рисунок А.6 показывает случай с
избыточными связями.
ПРИМЕЧАНИЕ Параллельные сети с байпасами терпимы из отказов самых двойных
компонентов.
45
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок А.5 - Пример сбоя одного компонента на ссылку на параллельных сетей
Рисунок А.6 - Пример сбоя одного компонента в качестве активного компонента на
параллельных сетях
А.2.4 Пример случаев отказа - Кольцевая топология
Отказ одного компонента в ссылке между активными компонентами не вызывает
неисправность сети, что показана на рисунке А.7.
Отказ одного компонента в качестве активного компонента может привести к снижению
сетевой функции, что показано на рисунке А.8. Однако, двойные самонаведения конечных
устройств, которые имеют избыточные ссылки на нескольких активных компонентов
(коммутаторы состава) могут продолжать общаться. Рисунок А.9 показан случай с
избыточными связями.
46
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок А.7 - Пример сбоя одного компонента на ссылку на кольцевой топологии
Рисунок А.8 - Пример сбоя одного компонента в качестве активного компонента на
кольцевой топологии
47
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок А.9 - Пример сбоя одного компонента в качестве активного компонентана
кольцевой топологии (с двойным самонаведения ED)
А.2.5 Пример случаев отказа - Лестничная топология
Отказ одного компонента в ссылке не вызывает сетевой сбой, который показан в рисунке
А.10.
В случае отказа одного из активной двухкомпонентной самонаведения конечных
устройств, которые имеют избыточные ссылки на множество активных компонентов
(коммутаторы состава) могут продолжать общаться; рисунок А.11 показывает случай с
избыточными связями.
Когда отказ двух компонентов происходит в звеньях разных местах, это может сохранить
полную функцию, если отказы не происходят в одинаковой компоненте для резервирования
одновременно, который показан на рисунке А.12.
При отказе двух компонентов на активных компонентах, он может или не может
поддерживать функцию сети в зависимости от положения отказа. Сеть работает со сбоями в
случае отказа, что показано на рисунке А.13, но она может быть частично функционировать,
если байпас применяется как показано на рисунке А.13.
R-NAT - перевод адреса железнодорожной сети
Обрыв на линии одного
компонента
Составные
выключатели
Полностью функционирующая сеть
48
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок A.10 - Пример Обрыва на линии одного компонента на постепенной
топологии
Авария
компонента при составном
выключателе
Составные
выключатели
Полностью функционирующая сеть
Рисунок A.11 – Пример аварии при включенном компонента на постепенной
топологии
Составные
выключатели
Двойной
обрыв на линии
Полностью функционирующая сеть
Рисунок A.12 - Пример двойного обрыва линии на постепенной топологии
Составные
Двойной обрыв
выключатели
на линии
Полностью функционирующая сеть (в случае обхода)
49
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок A.13 - Пример двойного обрыва линии на постепенной топологии (с обходом)
A3
Уровень избыточности ECN архитектуры
Есть три уровня избыточности, как описано в Таблице A.1. Рисунок A.14 показывает
примеры архитектуры ECN, которая поддерживает указанные уровни избыточности.
Таблица A.1 - уровень избытка ECN архитектуры
Уровень
избытка
Уровень 1
Описание
Компонент аварии
Нет избытка
Уровень 2
Никакой ошибки в сети нет, но некоторые функции не
выполнимы.
Ошибка CS
Сеть восстанавливаемая, но КУ,
соединенные с аварийными CS, не
могут связаться с другим КУ
Ошибка связи CS-CS
Сеть восстанавливаемая.
Ошибка связи CS-ED
ED с аварийной связью не может
связаться с другим КУ.
Никакой ошибки в сети нет и все функции в исправности.
Двойные аварии терпимы насколько возможно
Ошибка CS
Сеть восстанавливаемая и КУ,
соединенные с аварийными CS
могут связаться.
Ошибка связи CS-CS
Сеть восстанавливаемая.
.
Уровень 3
.
Ошибка связи CS-ED
Влияние на аварию
ED с аварийной связью может
продолжать связь
Уровень 1) Линейная топология
Уровень 2) Кольцевая топология
Уровень 3а) Параллельная сеть с двойным возвратом
50
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Уровень 3б) Кольцевая топология с двойным возвратом
Уровень 3в) Постепенная топология с двойным возвращением
Рисунок A.14 - Пример архитектуры ECN, классифицированная уровнем
избыточности
4
Анализ надежности уровня избыточности
Этот пункт анализирует надежность ECN с указанным уровнем избыточности.
Проанализированы три вида надежности. См. Таблицу A.2.
a) Общий показатель аварий
б) СВМА самой сети (сеть отсоединяется в случае неудачи); обрыв связи CS-ED не
рассматривается в анализе
c) СВМА связи между КУ (связь не возможна между КУ в случае аварии); обрыв связи CSED рассматривается в анализе
Предположения для упрощения следующие:
Значения
на различных уровнях избыточности не могут быть
эквивалентными, но используется то же самое значение
Для вычисления СВМА в связи между КУ, рассматривается только один
Таблица A.2 - Надежность уровня избыточности
Уровень
избыточно
сти
Уровень 1
51
Общий
показатель
аварий
СВМА самой сети
СВМА связи
междуКУ
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Уровень 2
Уровень
3а, 3б
Уровень
3в
Где:
N - количество CS
- показатель аварий CS
- показатель ошибки связи CS-CS
- показатель ошибки связи CS-ED
- скорость восстановления.
Таблица A.3 - Надежность, когда аварии частой причины рассматривают
уровень СВМА сети
избыточ
ности
3а,3б
СВМА связи междуКУ
3в
Таблица A.5 показывает примеры надежности и доступности архитектуры ECN, в
случае, если это параметры, описанные в Таблице A.4, используются для вычисления.
Значения в Таблице A.5 показывают, что уровень 3 архитектуры приносит более высокую
надежность и доступность, чем уровни 1 и 2. Однако уровень 3в немного превосходит уровни
3a и 3b в надежности и доступности, из-за многократных замен в избыточной сети. Уровни
3a, 3б, и 3в дают почти одинаковый уровень надежности и доступности из-за своей двойной
архитектуры возвращения.
Таблица A.4 - Параметры для вычисления надежности и доступности
Параметр
N - число CS или пар CS
Значение
Комментарии
- показатель аварий CS
10
5,00 х 10-6 (h-1)
MTTF: 200 000 h
- показатель ошибки связи CS-CS
3,33 х 10-7 (h-1)
MTTF: 3 000 000 h
3,33 х 10-7 (h-1)
MTTF: 3 000 000 h
- показатель ошибки связи CS-ED
- скорость восстановления.
Бета фактор
5,00 х 10-2 (h-1)
0,01
20 часов
1% аварии характерен
для избыточных
компонентов.
52
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Таблица A.5 - Надежность и ценности доступности в качестве примера
Уровень
избыточности
Полная
интенсивность
отказов
5,67х10-5
5,67х10-5
1,13х10-4
Уровень 1
Уровень 2
Уровень 3a, 3b
без CCF
Уровень 3c без
1,17х10-4
CCF
Уровень 3a, 3b с 1,13х10-4
CCF
Уровень 3c с
1,17х10-4
CCF
А.5
СВМА сети
1,88х104
1,76х104
8,79х106
СВМА
соединения
между КУ
1,76х104
1,88х104
7,79х106
Возможность
соединения между
КУ
0,9989(1,13х10-3)
0,9989(1,07х10-3)
0,999997(2,57х10-6)
3,06х107
2,93х107
0,9999993(6,82х10-7)
1,55х106
1,44х106
0,999986(1,39х10-5)
1,77х106
1,66х106
0,999988(1,2х10-5)
Избыточность концевых устройств
Было продемонстрировано, что ECN - надежная сеть, без рассматрения надежности КУ.
Но КУ не так надежен КУ обладает тем же самым порядок важности СВМА по сравнению с
CS; как пример, 200 000 ч. для каждого. Этот пункт показывает воздействие КУ и избыточного
КУ, на глобальной надежности.
Таблица A.6 показывает воздействие избыточности КУ на СВМА на всех уровнях
архитектуры. Таблица A.7 показывает воздействие избыточности КУ на СВМА
использование отношений, где отношение 1 соответствует СВМА 9 404 ч. Значения в обоих
таблицах вычислены параметрами, показанными в Таблице A.4.
В случае, если, где КУ избыточен, значения, данные ниже в Таблице A.6 и Таблице A.7,
показывают, что надежность увеличена значительно по сравнению с эффектом избыточности
в архитектуре.
Таблица A.6 - Надежность с сравнением избыточности КУ
Уровень избыточности
СВМА
без избыточности КУ
СВМА
с избыточностью КУ
Уровень 1
Уровень 2
Уровень 3a, 3b
Уровень 3c
9 404
9 677
19 696
19 774
19785
19 785
857 345
931 641
Таблица A.7 - Сравнение состояния СВМА
Уровень избыточности
Уровень 1
Уровень 2
Уровень 3a, 3b
Уровень 3c
ОтношениеСВМА
без избыточностиКУ
1
1
2,1
2,1
Приложение B
53
ОтношениеСВМА
с избыточностьюКУ
2,1
2
43,5
47,1
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
(информативное)
Перевод адреса железнодорожной сети (R-NAT)
B.1
Общий
R-NAT - алгоритм для сетевого 0
B.2
IP адрес местной подсети
Когда решение R-NAT будет развернуто, местный IP-адрес подсети ECN должен быть
связан с каждым КУ. Этот местный адрес подсети ECN взят в диапазоне подсети 10.0/9,
например 10.0/18. Пример IP отображения показан на рисунке B.1. В следующем, термин
«местный» будет использован вместо «местная подсеть ECN».
Занят
Состоит с подсетью id #63
../..
Состоит с подсетью id #1
Подсеть ETB #0, bb=3
Занят
Состоит с подсетью id #2
Состоит с подсетью id #2
../..
Состоит с подсетью id #2
Подсеть ETB #0, bb=2
Занят
Состоит с подсетью id #63
../..
Состоит с подсетью id #1
Подсеть ETB #0, bb=1
Занят
Состоит с подсетью id #63
../..
Состоит с подсетью id #1
Подсеть ETB #0, bb=0
Локальная подсеть ECN id#1
Адресное пространство
локальных подсетей
Рисунок B.1 - Пример ECN местного IP диапазона, «тень» модельного ряда IP
поездов для R-NAT
B.3
БУП R-NAT
54
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Поезд обеспечивает широкую связь между Концевыми Устройствами, которые
обладают только статическим IP источником, требует перевода сетевого адреса IP-адресов в
IP маршрутизаторах ECN/ETB. Этот сетевой перевод адреса должен в целом соответствовать
правилам, определенным в RFC 3022, но из-за специального использования в целях
направления ECN/ETB это упоминается как «перевод адреса железнодорожной сети» (RNAT).
Когда IP пакет будет разбит между ECN и ETB, следующие правила перевода адреса
должны применяться:
a) Во время направления от ECN к ETB, статический источник IP адреса должен быть
переведен с адресного уровня ECN на адресный уровень ETB, которое значит:
- адресное пространство уровня ETB применяется к источнику IP адреса
- источник Составной Сети Идентификатор Составной Сети должен быть заинтересован в IP
адрес источника
б) Во время направления от ETB до ECN, динамический IP Адрес получателя должен быть
переведен от ETB адресного уровня до уровня адреса ECN, который означает:
- адресное пространство уровня ETB применяется к источнику IP адреса
- CNI в IP адресе получателя должен быть удален (c заменен на«0»)
Пример - Пример должен показать перевод железнодорожной сети, см. на рисунок B.2.
Показаны три БУП, которые получили адреса БУП 05, 06 и 07 после принятия поезда.
Концевое Устройство с номером 53, соединен с БУП 05 и посылает IP пакет к КУ21, который
связан с БУП 07. БУП 05 переводит IP адрес источника от 10.0.0.53 (уровень адреса ECN) к
источнику IP адреса 10.129.64.53 (уровень адреса ETB). БУП 07 впоследствии переводит IP
адрес получателя 10.129.192.21 (уровень ETB) к IP адресу получателя 10.0.0.21 (уровень
ECN).
Рисунок B.2 - пример перевода железнодорожной сети (R-NAT)
B.4
Проблема совместимости между базовыми узлами поезда (БУП)
Поскольку БУП с R-NAT и БУП без (R-) NAT оба узнают общие определения
отображения IP, они совместимы. Примеры ниже иллюстрируют это, см. рисунки B.3 и B.4:
55
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок B.3 - от БУП c R-NAT к БУП
Рисунок B.4 - от БУП к БУП с R-NAT
В обоих случаях, на ETB IP-адреса всегда внутри отображения IP поезда. Локальные
IP-адреса, если определены, то никогда не используются в качестве адреса получателя к
коммуникабельному ECN.
56
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Приложение C
(нормативный)
Приемопередатчик с усиленным определением протокола сигналов
C.1 Общий
Это приложение определяет дополнительный приемопередатчик с усиленными
сигналами, которые могут быть использованы на открытом воздухе 10BASE-T МАУ или
100BASE-TX PMD.
Чтобы поднять шумовую неприкосновенность передачи сигнала на СМИ не только в
пределах транспортного средства, но также и соединяющихся транспортных средств со
сцепными приборами, сигналы передачи могут быть усилены в отличии от нормального
напряжения.
Есть два варианта согласно битрейту передачи, который может быть отобран в
зависимости от применения.
a) Приемопередатчик с усиленными сигналами для Физического Слоя, основанного на IEEE
802.3 пункт 14 (10BASE-T)
б) Приемопередатчик с усиленными сигналами для Физического Слоя, основанного на IEEE
802.3 пункт 25 (100BASE-TX).
C.2 Тип A: Приемопередатчик с усиленными сигналами для Физического Слоя,
основанного на IEEE 802.3 (10BASE-T)
C.2. 1 Общий
Этот пункт определяет приемопередатчик с усиленными сигналами для Физического
Слоя, основанного на IEEE 802.3, пункт 14 (10BASE-T).
Пункты, не определенные в этом пункте, должны быть совместимы с IEEE 802.3,
пункт 14 (10BASE-T).
C.2. 2 Единица приемопередатчика
Блок-схема единицы приемопередатчика показана на рисунке C.1. Отличительные
данные TD + и TD- о передаче сигналов МАУ IEEE 802.3 10BASE-T выровнены в усилителе.
Кондиционер уровня - схема, которая понижает полученные сигналы RDA + и RDA- в
диапазон приемлемого уровня сигнала, даже если это передано от соседнего
приемопередатчика.
Рисунок C.1 - Блок-схема единицы приемопередатчика для 10BASE-T МАУ
57
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
C.2. 3 Особенности сигнала передачи
Особенности сигнала передачи должны соответствовать описанию ниже.
a) Для формы сигнала дифференциала передачи сигнал выходного напряжения V0 определен
схемой показанной на рисунке C.2, в котором модель витой пары показана на рисунке C.3 с
сопротивлением на 100 Ом, чтобы соответствовать шаблону, показанному на рисунке C.4 и
Таблице C.1 с погрешностью ±10%. Эквивалентная схема технического требования кабеля
витой пары должны быть в соответствии с 14.3.1.2 в IEEE 802.3 (10BASE-T).
б) Сигнал TP_IDL должен удовлетворять условия, показанные на рисунке C.5 под нагрузкой,
показанным на рисунке C.6, где BT - период времени, который составляет 100 нс для 10BASET.
в) Когда будет использоваться пульс связи, условия, показанные на рисунке C.7, должны
быть удовлетворены. Когда статус связи может быть подтвержден без использования пульса
связи, то этот пункт может быть проигнорирован.
Рисунок C.2 - Отличительный тест выходного напряжения
Амплитуда продукции (нормализована)
Секция 1
Секция 2
Секция 3
Секция 4
Сопротивления в Ω
Емкости в pF
Индуктивности в mH
58
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок C.3 - модель Витой пары
.
Рисунок C.4 - Усиленный шаблон напряжения
Таблица C.1 - Показатели напряжения на выходе
59
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок C.5 - Форма сигнала усиленного передатчика начала TP_IDL
Рисунок C.6 – Начало TP_IDL контрольная нагрузка
60
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок C.7 - Форма сигнала усиленного передатчика для проверки частоты
C. 2.4 Особенности приемного сигнала
Форма приемного сигнала должна удовлетворять условиям шаблона, показанных на
рисунке C.8 и рисунке C.9.
Рисунок C.8 – Дифференциальное значение входного напряжения усиленного
приемника – сужение
61
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок C.9 - Дифференциальное значение входного напряжения усиленного приемника
– расширение
C.3 Тип Б: Приемопередатчик с усиленными сигналами для Физического Слоя,
основанного на IEEE 802.3 (100BASE-TX)
C.3. 1 Общий
Этот пункт определяет приемопередатчик с усиленными сигналами для Физического
Слоя, основанного на IEEE 802.3, пункте 25 (100BASE-TX).
Пункты, не определенные здесь, должны быть совместимы с IEEE 802.3, пункт 25
(100BASE-TX).
C.3. 2 Блок приемопередатчика
Блок-схема приемопередатчика показана на рисунке C.10. Дифференциальные данные
сигналов Transmit+ и Transmit- от IEEE 802.3 100BASE-TX PMD, выравниваются в схеме
усилителя и становятся сигналами TDA+ и TDA- , в последствии, ведутся к трансформатору.
Рисунок C.10 - Блок-схема приемопередатчика
62
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
C.3. 3 Особенности сигнала передачи
Особенности сигнала передачи должны соответствовать Пункту 9 ANSI X3.263:1995 за
исключениями ниже.
a) Пункт 9.1.1 Огражденная витая пара активного интерфейса продукции не должна
использоваться.
б) Контрольная нагрузка должна предоставляться с описанием пункт 9.1.2 Неогражденной
витой пары активного интерфейса продукции.
c) Для отличительного выходного напряжения вместо отличительного выходного напряжения
Vвн, будет:
3 800 мВ ≤ Vвн ≤ 4 200 мВ
Для активного интерфейса витой пары продукции, особенность Дифференциального Сигнала,
нулевой пик должен использоваться и выполнен в соответствии значениям в Таблице C.2
Таблица C.2 - Витая пара активного интерфейса продукции
Характеристики
Дифференциальный Сигнал, UTP,
нулевой пик
Дифференциальный Сигнал, UTP,
нулевой пик
Дифференциальный Сигнал,
нулевой пик
Минимум
Не используется
Максимум
Не используется
Ед. изм.
mVpk
Не используется
Не используется
mVpk
3 800
4 200
mVpk
C.3. 4 Характеристики приемного сигнала
Характеристики приемного сигнала должны соответствовать пункту 10.1 ANSI
X3.263-1995 с исключениями ниже.
a) Signal_detect, как должно утверждаться, за пункт 10.1.2 для любого действительного пика,
VSDA достигает максимума больше, чем 4 000 мВ. Signal_detect должен остаться
утверждаемым в присутствии действительных сигналов с низкой плотностью переходов.
б) Signal_detect должен быть неутвержденным, когда сигнал пик-пик будет меньше чем 800
мВ.
Рисунок C.11 иллюстрирует эти требования.
Рисунок C.11 - Порог утверждения Signal_detect
63
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Приложение D
(информативный)
Определение протокола постепенной топологии
D.1 Общий
Это приложение определяет протокол для постепенной топологии, которая
обеспечивает более высокую надежность и доступность в коммуникации поезда ,чтобы
минимизировать риск помехи.
Цели постепенной топологии, определенные в этом приложении.
Продолжение связи на ECN в случае аварии единственной составляющей
Продолжение связи на ECN в случае двойных аварий
Частой причиной, отказа сети для применения поезда в Концевых Устройствах,
если система может восстановиться в соответствующее время, избежав ошибки.
Для достижения целей, постепенная топология применяет следующую в философию
дизайна:
Двойные подсети магистральной связи вместе с Составными Выключателями,
которые дублируют систему,
Локальные связи между дублированным Составными Выключателями
Передача данных на обоих или любой из подсетей в зависимости от данных
приложения,
Специальные структуры команды, которые дополнительно используются в
протоколе Слоя Связи,
Протокол избыточности, который содержит информацию для управления и
восстановления.
Протоколы интерфейса для Составных Выключателей должны согласовываться с
общей частью этого стандарта кроме протоколов, которые нужны для управления
избыточностью в постепенной топологии.
Протоколы Концевых Устройств для Составных Выключателей должны согласоваться
с общей частью этого стандарта.
D.2 Архитектура составного сетевого узла
D.2. 1 Общий
Этот пункт определяет протоколы для CNN (Составной Сетевой Узел) в постепенной
топологии.
D.2. 2 Понятие постепенной топологии
Понятие постепенной топологии показана на рисунке D.1, в котором несколько CNN
связаны последовательно магистральными линиями в каждой подсети, которые указали как
sub-network 1 и sub-network 2, и также связаны между CNN на другой стороне сети для
создания пар с локальными линиями соответственно.
Концевое Устройство как правило имеет две линии, которые названы двойным
возвратом; обратитесь к 4.5.4.
64
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок D.1 - Понятие постепенной топологии
D.2. 3 Конфигурация постепенной топологии
Конфигурация постепенной топологии показана на рисунке D.2. К примеру, три CNN
в соответствующих подсетях, которые только соответствуют для упрощения части связи.
На рисунке D.2 в каждой подсети магистральная линия соединяет TPD и TPU, но TPU или
TPD открыты во внешней стороне CNN.
Для локальных линий, в случае ОД (Обработанные Данные) и управленческие данные
CNN LPT (местный порт для собственной подсети) исключителен для передачи структуры
данных, и LPR (местный порт для другой подсети) для приема. В других случаях каждый из
них используется в качестве двух путевого канала связи между подсетями. В sub-network 1
LPT связан с LPR в sub-network 2 и наоборот для другой локальной связи.
Рисунок D.2 - Конфигурация постепенной топологии
Основные потоки структур данных в дублированном CNN показаны на рисунке D.3.
Полученная структура в одном из портов ствола (TPU или TPD) передана к Слою Связи
CNN, другому порту связи ствола (TPU или TPD) и LPT одновременно.
С другой стороны структура данных от Слоя Связи CNN передана по связям ствола и
LPT одновременно.
Через LPR структуры данных, переданные от LPT другой подсети, получены другим
Слоем Связи в CNN.
65
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок D.3 - Основные потоки данных развиваются на магистральных линиях и
локальных связях в постепенной топологии
D.2.4 Функциональная структура Составного Сетевого Узла
Рисунок D.4 показывает функциональную структуру CNN, который состоит из секции
выключателя, оперативной секции MAC и части управления постепенной топологии.
Функция выключателя должна соответствовать Составному Выключателю,
определенного в этом стандарте.
Оперативный MAC выполняет управление сетью, чтобы избежать перегрузки трафика
для многократных доступов среди CNN посредством прохождения передачи структуры
данных к сети немедленно.
Примечание - 1. Протокол оперативного MAC определен в приложении D.3.2.5. Функция оперативного MAC исключение, которое не подлежит к IEEE 802.1D.
Секция управления постепенной топологии включает управление CNN, сток верхнего
слоя протокола, подслоя MAC и Физического Слоя. Управление CNN выполняет контроль за
избыточностью вместе с оперативным MAC при помощи специальных структур команды для
обнаружения и восстановления аварий
Примечание - 2. Протокол управления CNN определен в приложении Пункта D.4.
TPU и TPD на рисунке D.4 определяют направление течения. TPU должен быть связан
с TPD предыдущего CNN, также TPD должен быть связан с TPU последующего CNN, так,
чтобы символ всегда был получен в TPU и послан в TPD в CNN.
С другой стороны, когда CNN получает структуру данных в TPU или в TPD,
оперативный MAC проверяет заголовок структуры MAC, если это одна из специальных
структур команды, тогда это обработано в оперативном MAC, после этого, другая
специальная структура команды выпущена на магистральной связи.
Если полученная структура не специальная структура команды, то она передана в
следующий CNN через магистральный порт и одновременно распределена внешним
Устройствам Конца через выключатель, и также к мэнелжменту CNN через внутренний
интерфейс.
66
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок D.4 - Функциональная структура Составного Сетевого Узла
D.2.5 Хранилище трафика для обрабатываемых данных
Понятие хранилище трафика в данной постепенной топологии подобно Хранилищу
Трафика в WTB, определенном в IEC 61375-2-1, но адрес и размер набора данных PD зависят
от применения.
На рисунке D.5 понятие Хранилище Трафика показано как пример склада в сети с тремя
CNN.
Адрес погашения определяет стартовый адрес набора данных в адресном пространстве
Хранилища Трафика. Один издатель и многократные подписчики для набора данных
формируются как то же самое в обеих из подсетей. Все содержание данных наборов в
хранилище трафика обновлено к тому же самому в определенный период циклической
передачи.
67
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Размер адресного пространства Хранилища Трафика должен быть тем же самым в сети,
которая должна составить 64 килобайт. Два группы Хранилищ Трафика для подсети 1 и 2
должны быть осуществлены в Концевых Устройствах и CNN.
Рисунок D.5 - Понятие Хранилища Трафика в постепенной топологии
D.2.6 Избыточность в постепенной топологии
D.2.6.1 Общий
Этот подпункт описывает поведение избыточности в постепенной топологии, которая
использует специальные магистральные линии и специальные локальные связи как
избыточные маршруты.
D.2.6.2 Принципы избыточности в постепенной топологии
Рисунок D.6 показывает пример конфигурации постепенной топологии. CNN связан с
соседствующим CNN через магистральные линии и с партнером CNN на другой стороне
подсети через локальные связи так, чтобы они составили пару CNN.
Рисунок D.6 - Пример конфигурации постепенной топологии
Принципы избыточности в постепенной топологии;
68
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Все структуры PD (Обрабатывающие Данные) Концевых Устройств переданы к
обеим подсетям или магистралям связи обеих подсетей. Одновременно через соединенных
CNN, в которых данные идентичны, и структуры данных, могут быть получены Концевыми
Устройствами Конца.
Когда авария происходит на линии или в любой из подсетей CNN, которая
вызывает потерю данных из структур другие CNN берут на себя ответственность за передачу
данных как замена для аварийного CNN посредством хождения в обход с местными связями.
Передача замены применена только к PD. С другой стороны, в случае неудачи,
MD (Данные о сообщении), которые переданы к одной из подсетей, должны передаваться в
обход с протоколом маршрутизации OSPF, версия 2 определена в RFC 2328 с расширениями
1793 RFC и RFC 4136.
D2.6.3 Запасная передача
Запасная передача - резервная система, в которой передача данных в подсети CNN,
прерванная ошибкой, заменены другим CNN в подсети так, чтобы передача данных
продолжилась без вмешательства.
Посредством этого Концевые Устройства, связанные парами CNN двойного возврата,
не должны беспокоиться об аварии, чтобы переключить интерфейс на другую сторону для
получения данных.
В механизме запасной передачи, чтобы избежать условия, в котором CNN не может
получить данные PD от издателя CNN когда это подведено, так как данные с тем же самым
содержанием обычно передаются от партнера CNN издателя CNN при ошибке, данные могут
быть повторно переданы другим CNN как замена с использованием данных партнера.
На локальных линиях, принятые данные в LPR хранятся, чтобы обновить содержание
в Хранилищ Трафика для LPR, и затем когда запасная передача выполнена, данные берутся
для передачи к подсети.
Запасная передача должна быть начата на по следующим причинам:
a) Когда CNN обнаруживает ошибку магистральной линии между соседним CNN посредством
периодической проверки статуса магистральной линии,
б) Когда CNN обнаруживает один или более CNN, обойденного восходящим,
в) Когда CNN получает запрос, содержавшийся в информации об управлении CNN от другой
CNN.
В таких случаях CNN передает данные, полученные от группы CNN на другой стороне
подсети, читая данные из транспортного магазина, посвященного для LPR, в дополнение к его
собственным данным.
D.2.7 Параметры конфигурации для постепенной топологии
D.2.7.1 Общий
Этот подпункт описывает параметры конфигурации для постепенной топологии.
D.2.7.2 Параметры конфигурации для CNN
В постепенной топологии различные IP адреса должны быть назначены на
соответствующие Концевые Устройства с различными ID подсети, которые присоединены к
группе CNN в отдельных подсетях sub-network 1 и sub-network 2.
Таблица D.1 показывает параметр конфигурации для CNN в подсети 1, и Таблица D.2
показывает это для CNN в подсети 2 в постепенной топологии.
69
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Таблица D.1 - параметры конфигурации для CNN в подсети 1
Параметр
Тип
Описание
IndividualIpAddressIedS1
UNSIGNED32
Индивидуальный IP адрес
для управленческого CNN
подсети-1
IndividualIpAddressLprS1
UNSIGNED32
Индивидуальный IP адрес
для локального порта
подсети-1
Таблица D.2 - параметры конфигурации для CNN в подсети 2
Параметр
Тип
Описание
IndividualIpAddressIedS1
UNSIGNED32
Индивидуальный IP адрес
для управленческого CNN
подсети-2
IndividualIpAddressLprS1
UNSIGNED32
Индивидуальный IP адрес
для локального порта
подсети-2
D.2.7.3 Параметры конфигурации для запасной передачи
Таблица D.3 показывает параметры конфигурации для запасной передачи PD. Когда
функция запасной передачи будет применена в постепенной топологии,то число записей и его
содержания должно быть тем же самым для всей группы CNN в подсети.
Таблица D.3 – Конфигурация процесса запасной передачи
Параметр
ConfigurationSubsCnnK
Тип
Type_Configuration_Substitute
ConfigurationSubsCnnL
Type_Configuration_Substitute
ConfigurationSubsCnnM
Type_Configuration_Substitute
Описание
Данные конфигурации
запасной передачи CNN k
Данные конфигурации
запасной передачи CNN l
Данные конфигурации
запасной передачи CNN m
Таблица D.4 – Запасной тип конфигурации
Параметр
Тип
Описание
OffsetPdSubs1
UNSIGNED16 Адрес данных для packet 1 запасной
передачи
SizePdSubs1
UNSIGNED12 Размер данных для packet 1 запасной
передачи [0 ..1 464]
OffsetPdSubs2
UNSIGNED16 Адрес данных для packet 2 запасной
передачи
SizePdSubs2
UNSIGNED12 Размер данных для packet 2 запасной
передачи [0 ..1 464]
70
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
D.2.8 Связь сигнала для магистральной линии
D.2.8.1 Общий
Чтобы уменьшить вес и значение транспортных средств, чтобы сократить количество
проводов и контактов соединителя, особенно в случае применения ECN к существующим
транспортным средствам, используя традиционные электрические соединители между ними.
Посредством операции оперативного MAC в Слое Связи одновременная передача и прием
сигналов не происходят в связи так, чтобы единственный кабель витой пары мог
использоваться вместо двух кабелей витой пары с полной дуплексной работой, определенной
в этом стандарте, в случае Физического Слоя битрейт передачи в 10 Мбит/с с
приемопередатчиком усиления для более высокой надежности.
D.2. 8. 2
Единственная связь витой пары (Выбор)
Рисунок D.7 показывает блок-схему типа A приемопередатчика, определенного в
Приложении C, с единственной связью витой пары. Отличительные данные о передаче
сигнализируют о TD+ и TD-от МАУ IEEE 802.3 10BASE-T выровнены в усилителе, которые
становятся сигналами TDRD-и ведутся к трансформатору. Сигналы передачи и полученные
сигналы мультиплексные при продукции усилителя.
Рисунок D.7 - Блок-схема приемопередатчика для единственной связной витой пары
Связь сигнала для единственного кабеля витой пары дана в Таблице D.5, которая
показывает связь между этими двумя приемопередатчиками. И рисунок D.8 показывает
кабельное соединение единственным огражденным кабелем витой пары.
Таблица D.5 - Связь между приемопередатчиками
Рисунок D.8 - Кабельное соединение для единственной витой пары
71
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
D.2.9 Соединение локальной связи
Для местных портов связи в постепенной топологии ниже должен использоваться
соединитель, описанный ниже.
M12 D-кодированный соединитель
D.3 Уровень связи
D.3.1 Общий
Этот пункт определяет уровень Связи CNN для постепенной топологии.
Чтобы осуществить топологию лестницы, оперативный MAC принят к специальной
связи ствола между CNN в дополнение к функции MAC Составного Выключателя,
определенный в этом стандарте.
D.3.2 MAC - управление медиа доступом
D.3.2.1 Общий
Этот подпункт определяет протокол оперативного MAC, который выполняет
оперативный контроль, чтобы гарантировать детерминированную ответственность с более
коротким временем цикла.
Структуры команды для оперативного MAC также используются для обнаружения
ошибок и восстановления для постепенной топологии.
Посредством оперативного протокола MAC, определенного в этом подпункте,
альтернативная передача выполнена на магистральных линии потому, что оперативный
протокол MAC управляет движением так, чтобы только один CNN мог передать свою
структуру в подсети за один раз.
Управление потоками, определенное в IEEE 802.3 как операция MAC Control PAUSE,
должно быть поддержано в интерфейсах в InP и в ExP в режиме реального времени MAC,
которые показывают на рисунке D.4. Пункты, не определенные в этом подпункте, должны
быть совместимы с IEEE 802.3, Пункт 2 (Сервисная спецификация Управления доступом
СМИ).
D.3. 2. 2
Номер CNN
D.3. 2. 2.1
Общий
Отдельные номера CNN назначены на группу CNN, которые указывают на
последовательность CNN в сети. Формат номера CNN показан в Таблице D.6.
Таблица D.6 - номер CNN
Параметр
CnnNumber
Тип
UNSIGNED5
Описание
Номер CNN,
установленной
приложением и не
изменяемой в течении
операции [1..31]
D.3.2.2.2
Назначение номера CNN
Номер каждого CNN должен быть первоначально определен применением, которое
должно быть возрастающим от одного конца CNN к другому концу CNN. Номерам не
позволяют быть назначенными в прерывистом, нерегулярном или дублированными.
72
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Конечный CNN, назначенный с минимальным числом, называют как высший CNN и с
другой стороны, как самый нижний CNN. Направление от высшего CNN до самого нижнего
CNN называют как нисходящее направление, и противоположное направление восходящее
направление.
В постепенной топологии, как показано на рисунке D.9, например, в подсети 1, число
начинается с минимального номера 1 в том конца и увеличивается до другого конца CNN в
нисходящем направлении. В подсети 2 число должно быть назначено так же как у парного
CNN.
Рисунок D.9 - Пример назначения номера CNN в постепенной топологии
D.3. 2. 3
Определение структуры команды
D.3. 2. 3.1
Общий
Пять типов специальных структур команды для оперативного MAC определены и
должны быть применены к протоколу канала связи. Структуры команды применены только
между двумя соседними CNN за один раз. Таким образом, эти структуры команды не
передаются мгновенно к следующему CNN, но принимаются, интерпретируются и затем
повторно передаются к следующему CNN при необходимости.
a)
Команда сброса
Команда сброса дана от высшего CNN к нижнему CNN, чтобы синхронизировать
начало циклической передачи. Когда следующий CNN получает команду Сброса от верхнего
CNN, то CNN становится начальным состоянием, имеющим символ, и затем повторно
передает команду Сброса в следующего более низкого CNN и т.д.
б)
Символическая команда
Символическая команда применена, чтобы передать право передачи на следующего
CNN. CNN, который получил Символическую команду от верхнего CNN, разрешают передать
его собственные структуры данных к подсети. После того, как CNN передает структуры
данных, он передает Символическую команду к следующему более низкому CNN.
в)
Команда возврата
Команда возврата дана от самого нижнего CNN в восходящем направлении, чтобы
возвратить право передачи на высшего CNN. Когда промежуточный CNN получает команду
Возвращения от более низкого CNN, то CNN повторяет его к верхнему CNN соответственно.
г)
Команда связи
Команда связи применена, чтобы требовать нового CNN к подсети в самом нижнем
CNN. Если новый CNN запрашивает войти в подсеть, он посылает команду Связи-ACK взамен
команды Связи.
д)
Команда связи-ACK
Команда связи-ACK - ответ против команды Связи для присоединения к подсети.
Первоначально, один CNN ждет команды Связи от верхнего CNN. Когда CNN получает
команду Связи, CNN посылает команду Связи-ACK к верхнему CNN.
D.3. 2. 3.2
Форматы структуры команды
Формат структуры для команды показан на рисунке D.10, который сформирован в
минимальном размере рамки канала связи.
73
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
FCS
Код
проверки
Данные и дополнения
Дополнение
Команда
Адрес
источника
СФД
Арес
отправки
Преамбула
Рисунок D.10 - формат Структуры для команд
a)
Область адреса получателя
Особый адрес группы передачи должен быть назначен на область адреса получателя.
Конкретное область адреса получателя дана в Таблице D.7.
Область
Адрес получателя
Таблица D.7 - Содержание области Адреса получателя
Октеты в шестнадцатеричном числе
01 80 C2 00 00 01
б)
Область адреса источника
Особый адрес должен быть назначен на область адреса источника. Конкретное
количество области адреса источника дано в Таблице D.8.
Таблица D.8 - Содержание области Адреса источника
Область
Октеты в шестнадцатеричном числе
Адрес получателя
00 00 00 00 00 00
в)
Область Длины/Типа
Особое число должно быть назначено на область Длины/Типа. Конкретное
количество области Длины/Типа дано в Таблице D.9.
Таблица D.9 - Содержание области Длины/Типа
Область
Октеты в шестнадцатеричном числе
Длина/Тип
22 DF
г)
Область команды и кода
проверки
Два октета области команды применены к протоколу канала связи, и октет кода
проверки сделает команду надежней. Арифметика для кода проверки находится в
следующем.
Добавьте числа от первого октета области адреса получателя к последнему октету
области команды.
Области команда и код проверки должны быть установлены с числами,
определенными в Таблице D.10 соответственно.
74
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Таблица D.10 - Содержание команды и проверки кодирует области
д)
Область дополнения
Сорок три октета области дополнения должны быть установлены с конкретными
количествами, данными в Таблице D.11.
Таблица D.11 - Содержание области дополнения
Область
Октеты в шестнадцатеричном числе
Дополнение
00---------------00 (все 00 для 43
октетов)
ж)
Область Frame Check Sequence (Структура Цикла Проверки) (FCS)
Четыре октета Структура Цикла Проверки должны быть основаны на IEEE 802.3,
Пункт 3 (Структура структуры управления доступом СМИ).
D.3. 2. 4
Сетевая реконфигурация
D.3. 2. 4.1
Общий
Этот подпункт описывает учреждение связи для сетевой реконфигурации.
В этом подпункте, термин признанные средства связи не только физическая связь, но
и связь между Link и Link-ACK командует структурами.
D.3.2.4.2
Начальная конфигурация
В установке сети ниже должны быть применены правила начальной конфигурации.
а) Два магистральных порта в CNN ранее формируются как порт связи и другой для
нижнего порта связи. Физические связи между соседним CNN определены соответственно.
б) Два соседних CNN связаны магистральной линией между нижним портом связи
одного CNN и портом связи другого CNN.
75
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
в) В одном конце CNN, на котором наименьшее количество номера CNN назначено в
сети, как порт связи CNN и должен быть установлен в принудительную, но не для нижнего
порта связи.
г) На другом конце CNN, на котором большая часть номера CNN назначена в сети. В
нижнем порту связи CNN, должна быть установлена принудительную связь от способа, но не
для порта связи.
д) В другом промежуточном CNN ни нижние порты связи, ни верхние порты связи не
должны быть установлены в принудительную связь.
В CNN, в котором порт связи установлен в принудительную связь, передача структур
данных запрещена в порт связи кроме структуры команды Связи-ACK, отвечающей на
структуру команды Связи, если это получено в порту. С другой стороны в CNN, в котором
нижний порт связи установлен в принудительную связь от способа, передача структур данных
запрещена кроме структуры команды Связи.
D.3.2.4.3
Последовательность учреждения связи
a) Магистральные линии
Учреждение признанной связи между двумя CNN показано на рисунке D.11.
На рисунке D.11, верхний CNN или CNN J, после того, как приведено в действие,
передает структуру команды Связи к нисходящему CNN или CNN K через нижний порт связи
к порту следующего CNN, который повторен пока отправитель не получает структуру
команды Связи-ACK от следующего CNN.
С другой стороны, в более низком CNN или CNN K, после того, как приведено в
действие, когда CNN получает структуру команды Связи, он посылает структуру команды
Связи-ACK в верхнего CNN или CNN J, через порт связи.
Эти результаты подтверждения связи, что связь была установлена между двумя CNN.
Рисунок D.11 - Учреждение связи между двумя CNN
Эта процедура выполнена в каждой связи ствола между двумя соседними CNN в
подсети соответственно. Наконец признанные связи во всех портах ствола в подсети
установлены.
Если структуры команды Связи или структуры команды Связи-ACK обычно не
получаются в магистральной линии признал, что связь не установлена в связи ствола. В этом
случае признанные связи установлены в отделенных диапазонах последовательного CNN.
В постепенной топологии признанное учреждение связи выполнено независимо в
отделенных двух подсетях (см. рисунок D.12). После того, как все признанные связи между
CNN установлены в каждой подсети, сеть формирует область вещания в диапазоне между
обоими концами CNN в соответствующей подсети.
76
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок D.12 - Учреждение связи в постепенной топологии
b) Местная связь
Избыточные CNN в паре соединяют друг друга с двумя связями полного дуплекса
(см. рисунок D.13). Нормальные физические связи слоя, которые не признаны связи, должны
быть установлены в соответствующих местных связях.
Рисунок D.13 - Локальная связь между избыточными CNN
D.3.2.4.4
Определение способа CNN
Если CNN не получает структуры команды Связи в порт связи, то CNN оказывается в
высшем режиме CNN. Наоборот, если CNN не получает структуры команды Связи-ACK в
нижний порт связи, то CNN оказывается в самом нижнем режиме CNN.
CNN, которое признаны связях и в порте связи и в нижнем порте связи были
установлены, это оказывается в промежуточном способе CNN. Когда у CNN нет
установленной связи порта ствола, это оказывается в автономном способе CNN (см. рисунок
D.14).
Рисунок D.14 - Пример режимов CNN
77
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
В автономном режиме CNN становится не в сети, в котором ждет структура
команды Связи в порт связи и продолжает отправку структуры команды Связи каждые
2 мс нижнему порту связи до получения структуры команды Связи-ACK.
В обеих подсетях постепенной топологии способ CNN определен таким же образом.
Это решение принято CNN соответственно, как получено в итоге в Таблице D.12. Высший
CNN становится также владельцем сети.
При запуске сетей в постепенной топологии способы двух CNN в паре должны быть
идентичными.
Таблица D.12 – Режим CNN для CNN в постепенной топологии
D.3.2.4.5
Конец учреждения связи
CNN, который заканчивает связь, устанавливает процесс своего магистрального порта
для нижней связи, поскольку владелец по принципу «первым прибыл, первым обслужен»
посылает структуру команды Сброса в нисходящего CNN, чтобы начать циклическую
передачу.
Хотя CNN посылает команду Сброса рано, когда CNN получает любую структуру
команды в порт связи, то изменяет свой способ от высшего способа до промежуточного
способа. Наконец, фактический высший CNN становится владельцем, который начинает
циклическую передачу с символа, передающего подсеть. Циклическая передача выполнена в
соответствующей подсети в постепенной топологии.
Диаграммы состояния сетевой реконфигурации относительно символа описаны в
D.3.2.5.
D.3. 2. 5
Оперативный протокол MAC
D.3. 2. 5.1
Оперативная структура MAC
D.3. 2. 5.1.1 Общий
На рисунке D.15 коробки в Слое Связи означают блоки функций, которые составляют
MAC под уровень оперативного MAC. Стрелы с твердыми линиями среднего направления
прошли между коробками. Названия примитивов обозначены поблизости стрелы.
ACM (Машина Управления Доступом) берет на себя ответственность за управление
доступом сети. После того, как связь была установлена, ACM управляет символическим
прохождением и повторением полученных структур от одного магистрального порта к
другому магистральному порту.
TPCM (Машина Контроля за Магистральным портом) магистральный порт
управления признанной связи. TPCM посылает структуру команды Связи в нижний порт
связи, после того, как структура команды Связи-ACK была получена, устанавливает
78
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
признанную связь между нисходящим CNN. Когда структура команды Связи была получена
в порту связи, то TPCM передает структуру команды Связи-ACK обратно в порт связи, чтобы
установить признанную связь между восходящим CNN.
TRRC (Передача, Прием и Повторный Контроль) выпускает физический запрос
данных о слое, примитивный в соответствующем порту ствола с запрошенными данными от
ACM до TRRC. Примитив, полученный в порту ствола, десериализован, и затем послан в
ACM, TPCM и другой магистральный порт с соответствующим примитивом.
Рисунок D.15 - Структура оперативного подслоя MAC
D.3. 2. 5.1.2 Примитивы
Примитивы предоставляют услуги соответствующим структурным машинам.
Физические примитивы слоя опредены в IEEE 802.3, Пункт 6 также используются в
этом стандарте, которые перечислены в Таблице D.13.
79
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Таблица D.13 - Физические примитивы слоя
D.3. 2. 5.1.3 Переменные и параметры
Переменные и параметры, используемые в описании оперативного протокола MAC,
определены в Таблице D.14.
Таблица D.14 - Переменные и параметры для оперативного протокола MAC
Переменная и параметры
Описание
CnnMode
Один из способов CNN определен в
топологии; Верхний, Самый нижний,
промежуточный или автономный
forceOffTPU
Работает, когда магистральный порт для
верхней связи находится в принудительном
отключении
forceOffTPD
Работает, когда магистральный порт для
нижней связи находится в принудительном
отключении
ENInp
Приемлемое число структур от внутреннего
порта
ENExp
Приемлемое число структур от внешнего
порта
frame
Доставленная структура, с примитивными,
определенными значениями, которое
перечислены в таблице D.15
linkTPU
Работает, когда связь магистрального порта
установлена между восходящим CNN с
сцеплением команды Связи и команды
Связи-ACK
linkTPD
Работает, когда связь магистрального порта
установлена между нисходящим CNN
со сцеплением команды Связи и команды
Связи-ACK
receivingTPU
Работает, когда linkTPU рабочий и команда
Rest или Символическая команда
получена.
80
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
receivingTPD
VTL1
VTL2
VTLT
VTNORU
VTNORD
VTTRT1
VTTRT2
VTREQ
PortDirection
Наименование структуры
LINK
LINKACK
PAUSE0
PAUSEX
RESET
TOKEN
RETURN
81
Не работает, когда таймер TNORU
истекает, после того, как linkTPU
становятся рабочим.
Работает, когда linkTPD верен и команда
Возвращения получена.
Не работает то, когда таймер TNORD
истекает, после того, как linkTPD
становятся рабочим.
Набор значений к таймеру для цикла; 2 мс
произвольно для самого нижнего CNN и
автономного режима
Временная значение установлена в таймер
TL2 для задержки, посылающей команду
Связи-ACK после приема Связи 0,5 мс
произвольно
Временное значение , установленное в
таймер TLT для контроля реконфигурации;
15 мс
Набор временного значения в таймер
TNORU для контроля статуса приема в
магистральный порт
Набор временного значения в таймера
TNORD для контроля статуса приема в
магистральный порт
Временное значение , установленное
в таймер TTRT1; 8 мс
Временное значение , установленное в
таймер TTRT2; 9 мс
Временное значение для контроля
передает запрос структуры после отправки
PAUSE0 в порт
Работает , когда TPU соответствует
примитивам trc_data_tpu_req и
trc_data_tpu_ind и TPD к trc_data_tpd_req и
trc_data_tpd_ind.
Не работает, когда TPU соответствует
примитивам trc_data_tpd_req и
trc_data_tpd_ind и TPD к trc_data_tpu_req и
trc_data_tpu_ind.
Таблица D.15 - имя структур
Описание
Командная структура связи
Командная структура LINKACK
Структура с временем ПАУЗЫ 0
Структура с временем ПАУЗЫ х
Командная структура СБРОСА
Командная структура TOKEN
Командная структура ВОЗВРАТА
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
D.3. 2. 5.1.4 Таймеры
Таймеры, используемые в описании оперативного протокола MAC, определены в
Таблице D.16.
Таблица D.16 - Таймеры для оперативного протокола MAC
Таймеры
Описание
TL1
Период установки циклического магистрального порта
TL2
Время задержки после приема Связи
TLT
Таймер возврата в течении времени для Возврата команды
структуры, который должен быть больше, чем TTTRT2
TNORU
Таймер, чтобы обнаружить отсутствия приема сигнала в
TPU
TNORD
Таймер, чтобы обнаружить отсутствия приема сигнала в
TPD
TTRT1
Запускается при отправке или получении команды Сброса
структуры, при истечении времени CNN отправляет Символ
к следующему CNN, в случае самого нижнего CNN
посылает структуру команды Возвращения с разрешения
послать структуру данных для внутреннего порта, но запрет
для внешнего порта.
(TTTRT1≤ TTTRT2)
TTRT2
Запускается при отправке или получении команде Сброса
структурой при истечении времени CNN отправляет Символ
к следующему CNN, в случае самого нижнего CNN
посылает структуру команды Возвращения с запретом,
чтобы послать данные развиваются и для внутреннего порта
и для внешнего порта. (TTTRT1≤ TTTRT2)
TREQ
Таймер, для не обнаружения структуры данных порта,
которому разрешено посылка структуры PAUSE
D.3. 2. 5.1.5 Процедуры
Процедуры, которые характерны для оперативного протокола MAC, определены в
Таблице D.17.
Таблица D.17 - Процедуры оперативного протокола MAC
Процедуры
Описание
delay(timer)
Задержка с таймером
detectCNNLocation
initReconfiguration
Определенное начальное состояние
магистральных портов согласно
заданному способу CNN.
Для высшего способа CNN отключите
верхний порт связи и подключите нижний
Выполните следующую инициализацию,
необходимую для реконфигурации
82
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
a)
установите linkTPD False
b)
Пошлите структуры ПАУЗЫ со
временем TPAUSE к внутреннему и
внешнему порту. TPAUSE должен быть
больше, чем TCYCLE
startTimer(timer)
stopTimer(timer)
Запустите таймер. Если указанный таймер
работает, то происходит перезагрузка и
сброс.
Стоп
D.3. 2. 5.1.6 События
События, которые характерны для оперативного протокола MAC, определены в
Таблице D.18.
Таблица D.18 - События для оперативного протокола MAC
События
Описание
примитивный запрос
Запрос выпущен.
примитивный признак
Признак данных или статуса
expiredTimer (таймер)
Таймер, запущенный процедурой
startTimer, истек
D.3. 2. 5.2
Операция TRRC
D.3. 2. 5.2.1 Примитивы TRRC
Примитивы, определенные для операции TRRC, перечислены в Таблице D.19.
Таблица D.19 - примитивы TRRC
Имя
trc_data_tpu_req (структура)
Значение
Примитивный запрос к TPU
trc_data_tpu_ind (структура)
Примитивный признак от TPU
trc_data_tpd_req (структура)
Примитивный запрос к TPD
trc_data_tpd_ind (структура)
Примитивный признак от TPD
trc_data_inp_req (структура)
Примитивный запрос к InP
trc_data_inp_ind (структура)
Примитивный признак от InP
trc_data_exp_req (структура)
Примитивный запрос к ExP
trc_data_exp_ind (структура)
Примитивный признак от ExP
D.3. 2. 5.2.2 Примитивный запрос TRRC и операция
83
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Операция TRRC на принятие запроса определена в Таблице D.20.
После того, как TRRC принял запрос, выпущенный от ACM или TPCM пакетов,
полученные данные в структуре преобразовывают в последовательную форму, как
определено в IEEE 802.3, и выпускают запрос TRRC.
Таблица D.20 - операция TRRC на принятии примитивов запроса
Принятый запрос
Операция TRRC
trc_data_tpu_req
Полученные данные в структуре
преобразуют в последовательную форму и
выпускают ph_data_tpu_req
trc_data_tpd_req
trc_data_inp_req
trc_data_exp_req
Полученные данные в структуре
преобразуют в последовательную форму и
выпускают ph_data_tpd_req
Полученные данные в структуре
преобразуют в последовательную форму и
выпускают ph_data_inp_req
Полученные данные в структуре
преобразуют в последовательную форму и
выпускают ph_data_exp_req
D.3. 2. 5.2.3 Физический признак примитива и операции TRRC
TRRC делает структуру в формате IEEE 802.3 из сигналов, полученных в порту TPU,
TPD, InP или ExP с физическим признаком примитивный, и выпускает соответствующий
физический признак, примитивный от TRRC до TPCM и ACM.
Далее, в случае, если тот адрес получателя полученной структуры не соответствует
адресу получателя структуры Контроля MAC, то TRRC передается ко всем другим портам.
Таблица D.21 - операция TRRC на принятии физических признаков примитива
Принятый примитивный признак
Операция TRRC
ph_data_tpu_ind
ЕСЛИ адрес получателя (DA) не
соответствует адресу получателя (DA)
структура контроля оперативного MAC;
ТОГДА
Передайте DA и после сигналов
ко всем другим портам LPT, TPD, InP,
END IF
Делают структуру из полученных
сигналов и выпускают trc_data_tpu_ind и
trc_data_tpud_ind
ph_data_tpd_ind
ЕСЛИ адрес получателя (DA) не
соответствует адресу получателя (DA)
структура контроля оперативного MAC;
ТОГДА
Передайте DA и после сигналов
ко всем другим портам LPT, TPD, InP,
END IF
84
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
ph_data_inp_ind
ph_data_exp_ind
Делают структуру из полученных
сигналов и выпускают trc_data_tpu_ind и
trc_data_tpud_ind
ЕСЛИ адрес получателя (DA) не
соответствует адресу получателя (DA)
структура контроля оперативного MAC;
ТОГДА
Передайте DA и после сигналов
ко всем другим портам LPT, TPU, TPD
END IF
Делают структуру из полученных
сигналов и выпускают trc_data_tpu_ind и
trc_data_tpud_ind
ЕСЛИ адрес получателя (DA) не
соответствует адресу получателя (DA)
структура контроля оперативного MAC;
ТОГДА
Передайте DA и после сигналов ко
всем другим портам LPT, TPU, TPD, InP.
END IF
Делают структуру из полученных
сигналов и выпускают trc_data_exp _ind
D.3. 2. 5.3
Операция TPCM
D.3. 2. 5.3.1 Структурная машина TPCM
Рисунок D.16 показывает структурную машину протокола TPCM. Таблица D.22
показывает изменения состояния для TPCM. Процедуры в структурной машине TPCM в
Таблице D.23.
85
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок D.16 - Структурная машина TPCM
Текущее
состояние
Таблица D.22 - Изменения состояния TPCM
Событие
Действия
[условие]
Начальное
состояние
tpc_start_req ()
Инициировать
expiredTimer
(TNORD);
WAIT_LINK_
УСТАНОВЛЕ
Н
trc_data_tpu_in
d (структура)
trc_data_tpd_in
d (структура)
Следующая
структура
инициализируйте переменные и
Инициировать
запустите таймер TNOR D
receivingTPU = False;
receivingTPD = False;
startTimer(TNORD)
Когда таймер TNORD истекает,
WAIT_LINK_
укажите на статус связи и
УСТАНОВЛЕ
пошлите первую команду Связи
Н
updateTPUD (); trc_data_tpd_req
(СВЯЗЬ); startTimer (TL1);
delay(TL2);
WAIT_LINK_
trc_data_tpu_req(LINKACK);
УСТАНОВЛЕ
receivingTPD = True;
Н
updateTPUD();
startTimer(TNORU);
delay(TL2);
trc_data_tpu_req(LINKACK);
86
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
trc_data_tpu_in
d (структура)
trc_data_tpd_in
d (структура)
expiredTimer
(TNORU);
expiredTimer
(TNORD);
expiredTImer
(TL1)
receivingTPD = True;
updateTPUD();
startTimer(TNORU);
receivingTPD = Tru
updateTPUD();
startTimer(TNORD)
stopTimer(TL1);
receivingTPD = True;
updateTPUD();
startTimer(TNORD);
receivingTPU = False;
updateTPUD();
receivingTPD = False;
updateTPUD();
startTimer(TL1);
if (linkTPD != True)
{trc_data_tpd_req(LINK);}
startTimer(TL1);
Таблица D.23 - Процедуры в структурной машине TPCM
Процедура
updateTPUD ()
Описание
Обновите статус учреждения связи TPU и
TPD. На обнаружение изменения
tpc_link_status_ind.
if (receivingTPU != linkTPU || receivingTPD
!= linkTPD)
linkTPU = receivingTPU; linkTPD =
receivingTPD;
tpc_link_status_ind(linkTPU, linkTPD);
D.3. 2. 5.3.2 Примитивы TPCM
Примитивы, определенные для TPCM, перечислены в Таблице D.24.
Таблица D.24 - Примитивы TPCM
Имя
Значение
tpc_start_req ()
tpc_link_status_ind (stsTPU, stsTPD)
начните структурную машину TLC
признак магистральных портов
stsTPU: структура магистрального порта
для связи
stsTPD: структура магистрального порта
для связи
D.3. 2. 5.4
Операция ACM
D.3. 2. 5.4.1 Структурная машина ACM
Рисунок D.17 показывает структурную 5 показывает изменения состояния для ACM,
Таблица D.26 показывает изменения состояния для USE_TOKEN.
87
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок D.17 - Структурная машина ACM
Таблица D.25 - Изменения состояния ACM
Текущая
Событие [условие]
Действия
структура
Следующая
структура
Инициализация
вход
CHECK_LINK
CHECK_LINK
[forceOffTPU == True ||
linkTPU == False &&
linkTPD
== True]
[forceOffTPU == False &&
linkTPD == True]
Запуск
initReconfiguratio
tpc_start_req();
setForceOff();
-
-
WAIT_RESET
startTimer(TLT);
USE_TOKEN
INITIATE_
вход
INITIATE_TOKEN
88
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
TOKEN
WAIT_RESET
trc_data_tpd_ind (RESET)
WAIT_TOKEN
trc_data_tpu_ind(TO
KEN)
USE_TOKEN
usedToken
[forceOffTPD ==
False &&
linkTPD == True]
startTimer(TTRT1);
startTimer(TTRT2);
trc_data_tpd_req(RESE
T);
startTImer(TTRT1);
WAIT_TOKEN
startTimer(TTRT2);
if (forceOffTPD ==
False && linkTPD ==
True) {
trc_data_tpd_req(RESE
T);
Принятие TOKEN
USE_TOKEN
Остановите
USE_TOKEN
Загрузите
установленную
связь
trc_data_tpd_req(TOK
EN);
usedToken
Отправьте TOKEN
[forceOffTPD ==
вниз
True |
ждите RETURN
linkTPD == False]
trc_data_tpd_req(TOK
EN);
RETURN_T
вход
В нисходящем CNN
OKEN
отправьте RETURNв
верх
trc_data_tpu_req(RET
URN);
PASS_RET
trc_data_tpd_ind(RET В промежуточном
URN
URN)
CNN,отправьте
RETURN в верх
trc_data_tpu_req(RET
URN);
WAIT_RET
trc_data_tpd_int(RET В высшем CNN переURN
URN)в
запустите RETURN
Except
tpc_link_status_ind(st Конфигурация сети
INITIATE sTPU,
запущена
and
stsTPD)
CHECK_LI
expiredTimer(TLT);
Конфигурация сети
NK state
запущена
89
PASS_RETURN
WAIT_RETURN
WAIT_RESET
WAIT_RESET
INITIATE_TOKEN
CHECK_LINK
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок D.18 - Диаграмма структуры USE_TOKEN
Таблица D.26 - Изменения сструктуры USE_TOKEN
Текущая
структура
Событие [условие]
Действия
GRANT_InP
entry[ENInP != 0]
trc_data_inp_req(PAUSE0) GRANT_InP
;
numFrame = 0;
startTImer(TREQ)
GRANT_ExP
entry[ENInP == 0]
trc_data_inp_ind(frame);
numFrame++;
startTimer(TREQ);
expiredTimer(TREQ);
trc_data_inp_req(PAUSEX
);
trc_data_inp_req(PAUSEX
);
trc_data_inp_req(PAUSE);
numFrame >= ENIp;
expired(TTRT2);
Следующая
структура
GRANT_InP
GRANT_ExP
GRANT_ExP
Final state
90
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
GRANT_ExP
entry[ENExP != 0]
entry[ENExP == 0]
trc_data_inp_ind(frame);
expiredTimer(TREQ);
numFrame >= ENEx;
expired(TTRT2); ||
expired(TTRT1);
tpc_link_status_ind()
expiredTimer(TLT)
Any state
trc_data_exp1_req(PAUSE
0);
numFrame = 0;
startTImer(TREQ);
numFrame++;
startTimer(TREQ);
trc_data_exp_req(PAUSEX
);
trc_data_exp_req(PAUSEX
);
trc_data_exp_req(PAUSEX
);
Запуск конфигурации
Запуск конфигурации
GRANT_ExP
Final state
GRANT_ExP
Final state
Final state
Final state
Final state
D.3. 2. 5.4.2 Переменная
ACM использует местную переменную, определенную в Таблице D.27.
Переменная
Таблица D.27 - переменная для ACM
Описание
число полученных структур от
внутреннего порта или внешнего порта
во время CNN держит Символ
numFrame
D.3. 2. 5.5
Конфигурация для оперативного MAC
Параметры конфигурации для оперативного MAC определены в Таблице D.28.
Параметры конфигурации должны быть переданы с приложением и переданы к
оперативному MAC через управление CNN.
Таблица D.28 - параметры Конфигурации для оперативного MAC
Параметр
Тип
Значение
ТопологияСети
ForceSetCnnMode
ForcedCnnMode
91
ENUM2
BOOLEAN
1
ENUM2
ТопологияСети
[0]: Линейный
[1]: Занятый
[2]: Посепенный
[3]: Н/О
Force to set CNN mode
FALSE: No
TRUE: Yes
Когда ForceSetCnnMode TRUE, то ставьте
режим CNN
[0]: Режим ожидания
[1]: Высший режим
[2]: Нисходящий режим
[3]: Промежуточный режим
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
DisableTrunkTxrx
DirectionSwitch
PermitedPacketCountInp
CnnNumber
TotalNumberOfCnns
TransmissionLinkSubnetwor
kId
DataSizeProducerPacket1
DataSizeProducerPacket2
DataSizeCnnManagement
SubstituteTransmission
PermitedPacketCountSubs
EnableTargetTokenRotation
Time1
TargetTokenRotationTime1
EnableTargetTokenRotation
Time2
Запрет на передачу и принятие
магистральных портов
[0]: нет запрета
[1]: закрыт нижний порт связи
[2]: закрыт верхний порт связи
[3]: закрыты оба порта связи
BOOLEAN Включить направление магистральных
1
портов
FALSE: установить верхний порт к
Направлению_1 и нижний порт к
Направлению_2
TRUE: Установить в резерв
UNSIGNED Разрешенное количество
4
[0]: нет разрешения
[1.. 15]: число разрешенных пакетов
UNSIGNED Номер CNN: [1.. 31]
5
UNSIGNED Общее количество CNN: [1.. 31]
6
ENUM1
Идентефикация подсети для магистральной
линии (где находится CNN)
[0]: подсеть1
[1]: подсеть2
UNSIGNED Размер данных для пакета производителя 1
10
(N-1): [0.. 1 023]
UNSIGNED Размер данных для пакета производителя 2
10
(N-1): [0.. 1 023]
UNSIGNED Размер данных для управления CNN (N-1):
10
[0.. 1 023]
BOOLEAN Передача замены
1
FALSE: No
TRUE: Yes
UNSIGNED Разрешенный счет пакета для передачи
4
замены: [1.. 15]
Внутренне, разрешенный счет пакета для
внутреннего порта измененный на;
[PermitedPacketCountInp]+[PermitedPacketCo
untSubs]
BOOLEAN Target Token Rotation Time 1 (TTRT1)
1
FALSE: No
TRUE: Yes
UNSIGNED Target Token Rotation Time 1 (TTRT1),
7
чтобы держать символическое время
вращения передача ограничена за
исключением структуры данных во
внутреннем порту.
[1.. 127]: временное значение в единице
0,1мс
BOOLEAN Target Token Rotation Time 2 (TTRT2)
1
FALSE: No
ENUM2
92
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
TargetTokenRotationTime2
UNSIGNED
7
TRUE: Yes
Target Token Rotation Time 2 (TTRT2)
Чтобы держать символическое время
вращения передача ограничена за
исключением Символической структуры.
[1.. 127]: временное значение в единице 0,1
мс TTRT2 > TTRT1
D.3. 2. 5.6
Оперативный контроль
Во-первых, высший CNN или CNN 1 дает команду Сброса в подсети, после этого,
передает две структуры данных и последующую Символическую команду. Следующий более
низкий CNN или CNN 2 передает три структуры данных и последующую Символическую
команду. Затем, CNN 3 передает единственную структуру данных и последующую
Символическую команду. В то время как, CNN 4 передает три структуры данных и
последующую Символическую команду. Наконец, самый нижний CNN или CNN 5 передает
структуру данных и команду Возвращения.
После конца цикла от приема команды Возвращения Return CNN 1 предлагает
команду сброса RESET для следующего цикла. Когда CNN 1 не принимает команду
Return в лимит времени, тогда порт предлагает дать команду RESET обязательно.
R команда Reset
T команда Token
E команда Return
Dij структурные данные CNN
Рисунок D.19 - Пример последовательности передачи
Таблица D.29 – Элементы времени для последовательности передачи
Элементы времени
Описание
Tc
Время цикла в цикле; изменяется для
каждого цикла
Tc_MAX
Максимальное время цикла, можно
рассчитать
TLT
Лимитированное время для Return
TCMD
Время структуры команды; постоянная в
зависимости от команды.
93
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Предайте время промежутка структуры,
определенный в IEEE 802.3 с минимумом
Данные структурного времени;
Конец времени цикла
Время для передач CNN i данных;
варьируется в зависимости от суммы
данных
Максимальное символическое время
захвата для CNN i
TG
TFi
TM
Tni
thi
D.3. 2. 5.7
Сервисные параметры класса данных
Сервисные параметры класса данных CNN с оперативным MAC описаны в Таблице
D.30. Чтобы можно гарантировать детерминированную ответственность, максимальное
время цикла может быть вычислено с уравнениями для TC_MAX .
Таблица D.30 - сервисные параметры класса Данных
Класс
Парамет
Значение
данных
р
Обработайте Время цикла
данные
Время
ожидания
Комментарии
Как правило,
TC_MAX
меньше чем 10 мс
где
для 16; 128
TC_MAX
максимальное время октетов/CNN для
цикла;
10 Мбит/с, 1 280
TCMD время структуры команды октет/CNN для
(72x8 / BR);
100 Мбит/с.
N: Число CNN в сети;
TG
время промежутка структуры,
включая управление потоками время
структуры;
F Число структурных данных,
переданных на сеть;
TFi время для передачи данных ;
LHi длина преамбулы и заголовков
для MAC, IP и UDP или TCP в октетах
;
LDi
длина эксплуатационных
данных, развивающихся в октетах;
BR битрейт (10 Мбит/с или 100
Мбит/с);
TM предельное время в конце цикла
N=2.. 31 Немного
времени зависит
от
где
N:
Число CNN в сети между битрейта
передачи;
отправителем и targetEDs;
0,1µs для 10
TX время для структуры, чтобы
Мбит/с, 0,01µs
отослать (в зависимости от длины);
TBL Время ожидания прохождения для 100 Мбит/с.
CNN; 128 бита
94
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Данные о
сообщении
Данные о
потоке
Колебание
Время
ожидания
Колебание
Время
ожидания
Колебание
LLi Времена ожидания связи
между (i) th и (i+1) th
TCj Колебание, вызванное временем
цикла;
0 к TC_MAX;
(То же самое как у Обработанных
Данных)
(То же самое как у Обработанных
Данных)
(То же самое как у Обработанных
Данных)
(То же самое как у Обработанных
Данных)
Максимальное
усилие
Время
ожидания
Колебание
Контрольное
Время
ожидания
Колебание
(То же самое как у Обработанных
Данных)
(То же самое как у Обработанных
Данных)
(То же самое как у Обработанных
Данных)
(То же самое как у Обработанных
Данных)
D.3. 2. 5.8
Управление пропускной способностью
Полоса пропускания сети распределена как символические периоды владения
соответствующего CNN кроме предела времени цикла, в которое только CNN, может передать
свою структуру данных к сети.
В течение некоторой задержки времени в CNN Концевые Устройства, связанные с
CNN, разделяют время, чтобы передать данные.
Этим управляет разрешенное максимальное количество структуры и к целевому
символическому времени вращения в каждом CNN, которые предварительно
сконфигурированы применением.
QoS должен быть поддержан с функцией выключателя CNN согласно 4,6.
D.3. 3 IP-адрес и управление IP-адресом
D.3. 3. 1
Общий
Общий формат IP-адреса для ECN определен в этом стандарте. Этот подпункт
определяет область хозяина IP-адреса для сети в постепенной топологии. Назначение на
другие области, чем область хозяина должно следовать определению этого стандарта.
D.3. 3. 2
Отдельное назначение IP-адреса
Формат IP-адреса в этой сети должен согласоваться со следующим.
00001010.xxxxxxxx.xxinnnnn.dddddddd/18
Примечание
[x]
[i]
[n]
95
Таблица D.31 - Примечание для областей IP-адреса
Описание
(Согласно IP-адресу в этом стандарте.)
Расширение id подсети в ECN [0-1]
Число по умолчанию CNN [1-31]
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
[d]
a) Произвольное количество для
внутренних портов CNN;
[1]: Порт для управления CNN в подсети-1
[2]: Порт для управления CNN в подсети-2
[3]: Порт для местной связи с другой
стороны подсети в подсети-1
[4]: Порт для местной связи с другой
стороны подсети в подсети-2
[5-15]: Заняты
б) Для внешних Концевых Устройств
(См. ПРИМЕЧАНИЕ 3);
[0]: Не используемый
[1-254]: Номера устройств для КУ
[255]: Не используется
Примечание -1Различные ID подсети используются для каждой подсети 1 и 2.
Примечание 2 Номер CNN определен в D.3.2.2 в этом стандарте, который
назначен статически.
Примечание 3 IP-адреса для внешних Концевых Устройств могут быть назначены
динамично с диапазонами [n] и [d], избежав чисел по умолчанию, используемых
для внутренних портов CNN.
D.4 Управленческий протокол CNN
D.4. 1 Общий
Этот пункт описывает управленческий протокол CNN в постепенной топологии.
D.4. 2 Архитектура управления CNN
Рисунок D.20 показывает архитектуру управления CNN.
Управление CNN периодически обновляет управленческую базу данных CNN со
статусом связи и посылает статус связи как информацию об управлении CNN к другому CNN
с многоадресной передачей.
Когда CNN получает информацию об управлении от другого CNN, управление CNN
обновляет управленческую базу данных CNN со статусом связи, соответствующим источнику
CNN.
Выполняя вышеупомянутое периодически, а также в каждом изменении статуса связи,
каждый CNN возможен признать весь статус связи CNN и все целительное свойство CNN в
сети.
96
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок D.20 - Архитектура управления CNN
D.4. 3 Отдельная информация об управлении CNN
После циклических запусков передачи по подсетям, каждый CNN должен послать
свою отдельную информацию об управлении в подсети циклическим механизмом передачи с
управленческим протоколом CNN так, чтобы весь CNN мог получить всю отдельную
информацию об управлении другого CNN.
Отдельная информация об управлении CNN содержится в эксплуатационных данных
пакета UDP. Частота передачи отдельной информации об управлении CNN с такая же как у
PD.
Формат данных отдельной информации об управлении CNN показана в Таблице D.32
и параметры в Таблице D.33.
5
97
Таблица D.32 - информации об управлении отдельного формата CNN
1
1
1
1
1
1
9
8
7 6
5
4
3
2
4
3
2
1
0
CateVer
ServiceDataSize
reserved
reserved
null
Connection
Sts
Null
CnnSts
null
BypassedCnnDetect
SubsCnnExec
Null
ConnectionStsOth
null
CnnStsOth
(*)
(*)
BypassedCnnDetectOth (*)
SubsCnnExecOth (*)
CnnHltyCountOth (*)
null
CnnIpAddr3Oth (*)
CnnIpAddr4Oth (*)
reserved
ForcLinkOffSts
1
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
UpDwHead
reserved
reserved (96 octests)
CnnHealthyCount
null
CnnNr
SubsReqFlag1
SubsSrcCnnNr1
SubsDstCnnNr1
reserved
SubsCnnExecNr1
SubsReqFlag2
SubsSrcCnnNr2
SubsDstCnnNr2
reserved
reserved (48 octets)
Таблица D.33 - Описание параметров для отдельной информации об управлении CNN
Параметр
Тип
Описание
CateVer
UNSIGNED16
Категория и версии данных о передаче;
октет MSB указывает на информацию об
управлении CNN: '10'H, октет LSB
указывает на версию формата,
начинающегося с: '00'H.
ServiceDataSize
UNSIGNED16
Размер эксплуатационных данных
ConnectionSts
Type_Connect
ion_Status
UNSIGNED4
Статус связи CNN
CnnSts
BypassedCnnDetect
Type_CNN_Fl
ags
SubsCnnExec
Type_CNN_F
ags
ConnectionStsOth
BITSET4
Статус CNN
'0100'B: offline
'0010'B: ожидайте
'0001'B: на линии
другой: н/о
Обойденные флаги обнаружения CNN, для
каждого входа;
'1': обнаруженный обход, '0': ни один
Флаги для CNNs, за который запасная
передача выполнены другим CNNs
'1 ':executed, '0': ни один
Статус связи CNN в другой подсети в
постепенной топологии
cn_u_oth (0): верхний порт связи ('0 ':normal,
'1 ':abnormal)
cn_d_oth (1): нижний порт связи('0 ':normal,
'1 ':abnormal)
98
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
CnnStsOth
UNSIGNED4
BypassedCnnDetectOth
Type_CNN_Fl
ags
SubsCnnExecOth
Type_CNN_Fl
ags
CnnHltyCountOth
UNSIGNED8
CnnIpAddrOth
ForcLinkOffSts
Type_Ip_Addr
_3_4
BITSET8
UpDwHead
UNSIGNED8
CnnHltyCount
CnnNr
UNSIGNED8
UNSIGNED8
SubsCnnFlag
UNSIGNED8
SubsDstCnnNr
UNSIGNED8
SubsSrcCnnNr
UNSIGNED8
SubsCnnExecNr
Type_CNN_Fl
ags
cn_l_oth (2): местный порт для другой
подсети ('0 ':normal, '1 ':abnormal)
зарезервированный (3): n/a
Статус CNN в другой подсети
'0100'B: от линии
'0010'B: резерв
'0001'B: на линии
Другой: n/a
для CNN, которые были обнаружены, чтобы
быть обойденными в другой подсети
постепенной топологии
1st16 bits: (MSB) CNN 15 – CNN 1 (‘1’:
bypass detected, ‘0’: none)
2nd16 bits: CNN 31 – (LSB) CNN 16 (‘1’:
bypass detected, ‘0’: none))
для CNN, которые были обнаружены, чтобы
быть обойденными в другой подсети
постепенной топологии
'1 ':executed, '0': ни один
‘1’:executed, ‘0’: none
Нормальное количество CNN в другой
подсети лестничной топологии (модуль 256)
3-е и 4-е октеты IP-адреса CNN в другой
подсети постепенной топологии (*1)
not used (0)-(5): null
ulp_f_off (6): up link port forced link off (‘1’:
forced off, ‘0’: none)
dlp_f_off (7): down link port forced link off
(‘1’: forced off, ‘0’: none
(0: Intermediate, 1: Up head, 2: Down head, 3255: n/a)
CNN healthy count (modulo 256)
CNN number (1 – 31: valid, 0 and 32 – 255:
n/a)
Substitute transmission request flag
(0: none, 1: requested, 2 -255: n/a
Substitute transmission destination CNN
number
(1 – 31: valid, 0 and 32 – 255: n/a)
Substitute transmission source CNN number
(1 – 31: valid, 0 and 32 – 255: n/a)
Flags for CNNs for which the substitute
transmission are executed
by other CNNs in the requested CNNs
‘1’:requested, ‘0’: none
Таблица D.34 – Статус_Типового_Соединения
Название типа
99
Тип
Описание
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Type_Connection_Status
Статус соединения портов в
CNN
cn_u (0): up link port
(‘0’:normal, ‘1’:abnormal)
cn_d (1): down link port
(‘0’:normal, ‘1’:abnormal)
cn_l (2): local port for the
other sub-network(‘0’:normal,
‘1’:abnormal)
reserved (3): n/a
UNSIGNED4
Таблица D.35 - Type_CNN_Flags
5
5
1
1
4
1
4
3
0
1
3
1
3
3
9
1
2
1
2
2
8
1
1
1
1
2
7
1
0
1
0
2
6
1
9
8
7
6
5
4
3
2
1
0
1
9
8
7
6
5
4
3
2
1
0
2
5
2
4
2
3
2
2
2
1
2
0
2
9
1
8
1
7
1
6
1
Таблица D.36– Type_Ip_Addr_3_4
Название типа
Тип
ip_ad_3_4
UNSINED16
Описание
3-й и 4-й октеты IP адреса
D.4. 4 Управленческая база данных CNN
После того, как больше чем один раз цикл отдельной информации об управлении CNN
пройдет, каждый CNN должен вычислить управленческую базу данных об управлении CNN,
полученной от другой группы CNN. Содержание базы данных становится идентичным среди
всей CNN в сети.
Параметры с флажками в управленческой базе данных CNN вычислены в логическом
ORed идентичных частей во всей отдельной информации об управлении CNN. Параметры с
численными значениями упакованы в один параметр для всего CNNs.
Таблица D.37 перечисляет параметры управленческой базы данных CNN.
Таблица D.37 - Параметры управленческой базы данных CNN
Параметр
Тип
Описание
BypassedCnnDetectAll1
BypassedCnnDetectAll2
(*)
SubsCnnExecAll1
SubsCnnExecAll2 (*)
ConnectionStsAll1
Type_CNN_Flag
s
Type_CNN_Flag
s
Type_CNN_Flag
s
Type_CNN_Flag
s
Type_Connection
_Status_All
подсеть-1 для каждого входа;
‘1’: bypass detected, ‘0’: none
подсеть-2 для каждого входа
‘1’: bypass detected, ‘0’: none
Флажки, запущенные в подсети-1
‘1’:executed, ‘0’: none
Флажки, запущенные в подсети-2
‘1’:executed, ‘0’: none '0001'B: на линии
другой: н/о
Состояние связи в подсети-1
100
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
ConnectionStsAll2 (*)
IpAddrAll1
IpAddrAll2 (*)
OnlStsAll1
OnlStsAll2 (*)
StbyStsAll1
StbyStsAll2 (*)
HltyCountAll1
HltyCountAll2 (*)
Type_Connection
_Status_All
Type_Ip_Addr_3
_4_All
Type_Ip_Addr_3
_4_All
Type_CNN_Flag
s
Type_CNN_Flag
s
Type_CNN_Flag
s
Type_CNN_Flag
s
Type_Healthy_C
ount_All
Type_Healthy_C
ount_All
Состояние связи в подсети-2
Индивидуальный IP адрес для всех CNN в
подсети-1
Индивидуальный IP адрес для всех CNN в
подсети-2
Онлайн статус для всех CNN в подсети-1
‘1’: On-line, ‘0’: None
Онлайн статус для всех CNN в подсети-2
‘1’: On-line, ‘0’: None
Статус ожидания для всех CNN в подсети-1
‘1’: On-line, ‘0’: None
Статус ожидания для всех CNN в подсети-2
‘1’: On-line, ‘0’: None
Нормальное количество для всех CNN в
подсети-1
Нормальное количество ля всех CNN в
подсети-2
Таблица D.38 - Type_Connection_Status_All
Таблица D.39 - Type_Ip_ Addr_3_4_All
Таблица D.40 - Type_Healthy_Count_All
101
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
D.4. 5 Примитивы для управленческого протокола CNN
Управление CNN использует примитивы для более низкого слоя протокола,
перечисленного в Таблице D.41.
Таблица D.41 - Примитивы более низкого слоя протокола для управления CNN
Примитивы
Описание
send_CnnInfo
Отправка информацию об
управлении CNN на уровень
транспорта
recv_CnnInfo
Принятие информацию об
управлении CNN от транспортного
уровня
D.4. 6 Параметры для управленческого протокола CNN
Параметры для управления CNN перечислены в Таблице D.42, которые используются
в D.4.8.
Таблица D.42 - Параметры для управления CNN
Параметр
Тип
Описание
Topology
ENUM2
CnnMode
ENUM2
MyCnn
MaxCnn
TokenCnn
UNSIGNED5
UNSIGNED5
UNSIGNED5
StatTpu
ENUM1
Network topology;
LINEAR (linear topology) or LADDER
(ladder topology)
Режимы CNN;
Высший (Uppermost CNN mode),
Нижний (Lowermost CNN mode),
Промежуточный (Intermediate CNN mode)
или
Ожидающий(Stand alone CNN mode)
номер CNN; [1.. 31]
Максимальное количество CNN
Количество CNN в структуре команды
Token
Статус магистрального порта связи;
Нормальный: когда связь на струтуре порта
(linkTPU == Работает ) длится больше, чем
предел таймера TRTPU
102
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
StatTpd
StatLpr
ForceOffTpu
ForceOffTpd
SubsCnnFlags
TempSubsCnnFlags
Ошибка: когда связь от структуры порта
(linkTPU == Не работает ) длится больше,
чем предел таймера TFTPU.
ENUM1
Статус магистрального порта для нижней
связи;
Нормальный: когда связь на структуре
порта (linkTPD == Работает) длится
больше, чем предел таймера TRTPD,
Ошибка: когда связь от структуры порта
(linkTPD == Не работает ) длится больше,
чем предел таймера TFTPD.
ENUM1
Статус местного порта для другой подсети;
Нормальный: когда связь на структуре
порта длится больше, чем предел таймера
TRLPR,
Ошибка: когда связь от состояния местной
связи длится больше, чем предел таймера
TFLPR.
BOOLEAN1
Статус TPU
True: Forced off
False: Not forced off
BOOLEAN1
Статус TPD
True: Forced off
False: Not forced off
Type_CNN_Flags Флажки , которые заменяют CNN.
Положения в SubsCnnFlags соответствует
тому из CNN:
«1»: CNN заменяет этот CNN,
«0»: CNN не заменяет этот CNN.
Type_CNN_Flags Временные флажки для CNN, которые
заменяют этот CNN, который сохранен
временно, чтобы послать впоследствии в
subusXmit () процедуру.
Содержание и форма TempSubsCnnFlags
совпадают с
SubsCnnFlags.
D.4. 7 Таймеры для управленческого протокола CNN
Таймеры для управления CNN перечислены в Таблице
D.43.
Таймеры
TNMS
TFTPU
103
Таблица D.43 - Таймеры для управления CNN
Описание
Таймер для периодической отправки
информации об управлении CNN;
значение по умолчанию составляет 100 мс.
Таймер для магистрального порта связи,
значение по умолчанию составляет 30 мс.
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
TRTPU
TFTPD
TRTPD
TFLPR
TRLPR
Таймер для магистрального порта связи,
значение по умолчанию составляет 0 мс
Таймер для магистрального порта для
нижнего порта связи, значение по
умолчанию составляет 30 мс
Таймер для магистрального порта для
связи, значение по умолчанию составляет 0
мс.
Таймер для местного порта для другой
подсети, значение по умолчанию
составляет 30 мс.
Таймер для местного порта для другой
подсети, значение по умолчанию
составляет 0 мс.
D.4. 8 Процедуры управленческого протокола CNN
D.4. 8. 1
Процедуры и функции
Процедуры для управления CNN перечислены в Таблице D.44, и связанные с этим
функции описаны в Таблице D.45 и Таблице D.46.
Таймеры
TNMS
TFTPU
TRTPU
TFTPD
TRTPD
TFLPR
TRLPR
Таблица D.44 - Процедуры для управления CNN
Описание
Таймер для периодической отправки
информации об управлении CNN;
значение по умолчанию составляет 100 мс.
Таймер для магистрального порта связи,
значение по умолчанию составляет 30 мс.
Таймер для магистрального порта связи,
значение по умолчанию составляет 0 мс
Таймер для магистрального порта для
нижнего порта связи, значение по
умолчанию составляет 30 мс
Таймер для магистрального порта для
связи, значение по умолчанию составляет 0
мс.
Таймер для местного порта для другой
подсети, значение по умолчанию
составляет 30 мс.
Таймер для местного порта для другой
подсети, значение по умолчанию
составляет 0 мс.
Таблица D.45 - Функции для замены передачи в CNN
Наименование функции
Операции
104
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
genSubsXRqBNStat ()
isOthCnnTPD(n)
105
Вычислите различие между TokenCnn и MyCnn. Если
различие больше чем 1, то,
создайте информацию для передачи замены в отдельной
информации об управлении CNN, так как предыдущий
CNN обойден. (SubsReqFlag1, SubsDstCnnNr1,
SubsSrcCnnNr1 и SubsCnnExecNr1)
Если различие равняется 1, то информацию очищают
для передачи замены к 0, так как никакой CNN не
обойден,
prevSubsDstCnnNr1 = SubsDstCnnNr1;
prevSubsCnnExecNr1 = SubsCnnExecNr1;
if ((MyCnn– TokenCnn) > 1) {//При обнаружении одного
или более обойденного CNN (), if (isOthCnnTPD(myCnn–
1) == Normal) {if (isOthCnnHealty(MyCnn, MaxCnn))
{SubsDstCnnNr1 = getMinCnnHealtyOthCnn(MyCnn,
MaxCnn);
SubsCnnExecNr1 = setBits(TokenCnn + 1, MyCnn– 1);
} else if (isOthCnnHealty (1, TokenCnn)) {
SubsDstCnnNr1 = getMaxCnnHealtyOthCnn(1, TokenCnn);
SubsCnnExecNr1 = setBits(TokenCnn + 1, MyCnn– 1));
} else{
SubsDstCnnNr1 = 0; SubsCnnExecNr1 = 0;
}
else if (isOthCnnTPU(TokenCnn + 1) == Normal) {
if (isOthCnnHealty (1, TokenCnn)) {
SubsDstCnnNr1 = getMaxCnnHealtyOthCnn(1, TokenCnn);
SubsCnnExecNr1 = setBits(TokenCnn + 1, MyCnn– 1);
} else {
SubsDstCnnNr1 = 0; SubsCnnExecNr1 = 0;
}
} else {
SubsDstCnnNr1 = 0; SubsCnnExecNr1 = 0;
}
} else {
SubsDstCnnNr1 = 0; SubsCnnExecNr1 = 0;
}
if (SubsDstCnnNr1 != 0) {
SubsReqFlag1 = 1; SubsSrcCnnNr1 = MyCnn;
} else {
SubsReqFlag1 = 0; SubsSrcCnnNr1 = 0;
}
if (prevSubsDstNr1 != SubsDstNr1 || prevSubsCnnExecNr1
!=
SubsCnnExecNr1)
return TRUE;
return FALSE;
Верните статус нижней связи CNN, определяемого с (n),
который является
подсоединенной с другой стороны подсети.
Нормальная структура : когда CNN нормален
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Ошибка: когда CNN не работает.
isOthCnnTPU (n)
isOthCnnHealthy (n1, n2)
getMinCnnHealthyOthCnn
(n1,n2)
setBits(n1, n2);
Верните статус нижней связи CNN, определяемого с (n),
который является
подсоединенной с другой стороны подсети.
Нормальная структура : когда CNN нормален
Ошибка: когда CNN не работает.
Если местные порты CNN, определяемые от n1 до n2 в
той же самой подсети нормальны, и соответствующие
CNN в другой стороне подсети здоровы, то затем
возвращается нормальная структура .
Если местные порты CNN, определяемые от n1 до n2 в
той же самой подсети нормальны, и соответствующие
CNN в другой стороне подсети здоровы, то затем
возвращается нормальная структура .
Установите «1» для битов от 2^ (n1) к 2^ (n2).
Таблица D.46 - Функции для передачи замены в связи
Наименование функции
Операции
genSubsXRqTPStat(statTPU,
statTPD)
Запустите информацию структуры запроса для
передачи замены согласно статусу магистральных
портов TPU и TPD. (SubsReqFlag2,
SUbsDstCnnNr2, SubsCnnExecNr2 и
SubsSrcCnnNr2)
if ((StatTpu == Failure) && (StatTpd == Normal)) {
// in case of failure at trunk port for up link
if (isOthCnnHealty (MyCnn, MaxCnn)) {
SubsDstCnnNr2 = getMinCnnHealtyOthCnn(MyCnn,
MaxCnn);
SubsCnnExecNr2 = setBits(1, MyCnn– 1);
} else
SubsDstCnnNr2 = 0;
} else if ((StatTpu == Normal) && (StatTpd == Failure))
{
// in case of failure at trunk port for down link
if (isOthCnnHealthy (1, MyCnn-1)) {
SubsDstCnnNr2 = getMaxCnnHealthyOthCnn(1,MyCnn1);
106
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
SubsCnnExecNr2 = setBits(MyCnn + 1, MaxCnn);
} else
SubsDstCnnNr2 = 0;
} else
SubsDstCnnNr2 = 0;
if (SubsDstCnnNr2 != 0) {
SubsReqFlag2 = 1; SubsSrcCnnNr2 = MyCnn;
} else
SubsReqFlag2 = 0; SubsSrcCnnNr2 = 0;
D.4. 8. 2
События
События для управления CNN перечислены в Таблице D.47.
Таблица D.47 - События для управления CNN
События
Описание
Reset или Power ON
Сброс данных
receivedToken(Cnn)
Принятие символа с номером CNN
changeTPUD (statTPU,
Изменение происходит в статусе
statTPD)
магистрального порта связи, который
показывает ошибку
changeLPR(statLPR)
Изменение происходит в статусе
магистрального порта связи, который
показывает ошибку
expiredTimer(timer)
Истекает таймер, начатый startTimer
D.4. 9 Эксплуатация управленческой машины CNN
Рисунок D.21 показывает диаграмму состояния для управленческой машины CNN.
Изменения состояния описаны в Таблице D.48.
107
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок D.21 - Диаграмма состояния для CNNMM
Текущая
структура
Initial state
INITIATE
Таблица D.48 - Изменения состояния CNNMM
Событие [условие]
Действия
Reset or Power ON
changeTPUD(statTPU,
statTPD)
// Reset or power on
tpc_start_req();
initNDB();
startTimer(TNMS);
tokenCnn = 0;
Следующая
структура
INITIATE
// Замена статуса связи
магистральных портов
updateMyNDB(statTPU,
statTPD);
if (topology == LADDER) {
108
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
INITIATE
receivedToken(Cnn)
[Topology == LADDER]
INITIATE
recv_CnnInfo(CnnInfo)
INITIATE
changeLPR(statLPR)
INITIATE
expiredTimer(TNMS)
genSubsXRqTPStat(statTPU,
statTPD);
}
buildCnnInfo(cnnInfo);
send_CnnInfo(cnnInfo);
subsXmit();
tokenCnn = cnn;
if (genSubsXRqBNStat() ==
TRUE) {
buildCnnInfo(cnnInfo);
send_CnnInfo(cnnInfo);
}
subsXmit();
Примите информацию
менеджмента от другого CNN
cnn = sourceCnn(cnnInfo);
updateNDB(cnn, cnnInfo);
subsXmit();
Замена структуры связи
местного порта для другой
подсети
updateMyNDB(statLPR);
buildCnnInfo(cnnInfo);
send_CnnInfo(cnnInfo);
Таймер TNMS
updateMyNDB(healthyCounter);
updateMyNDB(healthyCounter);
buildCnnInfo(cnnInfo);
send_CnnInfo(cnnInfo);
startTimer(TNMS);
INITIATE
INITIATE
INITIATE
INITIATE
D.4. 1 0
Назначение числа порта на управленческий протокол CNN
Для совместимой передачи данных назначения порта в Транспортном уровне
управленческого протокола CNN, перечисленного в Таблице D.49, должны использоваться в
произвольно, и не должны быть дублированы с числами порта.
Таблица D.49 – Произвольный номер порта для управленческого протокола CNN
Протокол
Порт назначения
Исходный порт
управленческие данные CNN (UDP) 49 154
49 154
D.5 Случаи аварии в постепенной топологии
D.5. 1 Общий
Этот пункт описывает различные случаи аварии в постепенной топологии, в которой
реконфигурация путей передачи за выполнена функцией запасной передачи.
D.5. 2 Случаи аварии
В дальнейшем различные случаи аварии показывают с примерами пяти пар подсети
CNN в постепенной топологии.
109
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
ОТМЕТЬТЕ В цифрах в этом пункте, впредь, примеры принимают пять пар подсеть
CNN в постепенной топологии. Не все Концевые Устройства, приложенные к соединенному
CNNs в двойном возвращении, иллюстрированы для упрощения. Толстые стрелы означают
структуры данных, переданные по подсети 1, и тонкие стрелы те по подсети 2. CNN,
обозначенный, заштриховывая коробку, подразумевает, что CNN выполняет передачу
замены. Номера CNN не фактические, но абстрактные для объяснения.
a)
Нормальное функционирование
На рисунке D.22 данные, порожденные из приложенного Концевые Устройства,
переданы и к подсети 1 и к 2 одновременно, и также поставлены CNNs в другой стороне под
- сеть взаимно через местные связи в каждом из CNNs.
Рисунок D.22 - Нормальная конфигурация путей передачи в постепенной
топологии
б)
Единственная авария связи в подсети
На рисунке D.23, в случае аварии связи в подсети 1, CNN 41 использует данные,
полученные от CNN 12, CNN 22 и CNN 32 через локальную связь CNN 42, чтобы повторно
передать данные к одной неповрежденной части sub-network 1, в котором данные те же,
которые должны быть получены от CNN 11, 21 и 31 соответственно.
С другой стороны, CNN 31 использует данные, полученные от CNN 42 и CNN 52 через
местную связь между CNN 32, чтобы повторно передать данные к другой неповрежденной
части sub-network 1, в котором данные те же, которые должно быть получены от CNN 41 и
CNN 51 соответственно.
Рисунок D.23 - Реконфигурация путей передачи с единственной аварии связи
в подсети
в)
Единственная авария CNN в подсети
На рисунке D.24, в случае аварии CNN в sub-network 1, связь CNN обойдена со схемой
реле. CNN 32 работает на резервную копию неудавшегося CNN 31.
CNN 41 использует данные, полученные от CNN 32 в местной связи через CNN 42,
которые являются тем же самым, что должны быть получены от CNN 31, чтобы повторно
передать данные к sub-network 1, как запасная передача.
110
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
Рисунок D.24 - Реконфигурация путей передачи с единственной аварией CNN в подсети
г)
Двойные аварии связи в подсети
На рисунке D.25, в случае двойных аварий связь в sub-network 1:
CNN 21 выполняет запасную передачу CNN 31, 41 и 51,
CNN 31 выполняет запасную передачу CNN 11 и 21,
CNN 41 выполняет запасную передачу CNN 51,
CNN 51 выполняет запасную передачу CNN 11, 21, 31 и 41.
Рисунок D.25 - Реконфигурация путей передачи с двойными авариями в связи
подсети
д)
Двойные аварии в обеих подсетях
На рисунке D.26, в случае двойных аварий :
CNN 21 выполняет запасную передачу CNN 31, 41 и 51,
CNN 31 выполняет запасную передачу CNN 11 и 21,
CNN 32 выполняет запасную передачу CNN 42 и 52,
CNN 42 выполняет запасную передачу CNN 12, 22 и 32.
Рисунок D.26 - Реконфигурация путей передачи с двойными авариями связи в
обоих подсетях
111
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
ж)
Двойные аварии CNN в обоих подсетях
На рисунке D.27, в случае аварии CNN авария в подсети 1 и другая авария CNN в
подсети 2;
CNN 31 выполняет запасную передачу CNN 21 в подсети 1, при помощи данных от
CNN 22,
CNN 52 выполняет запасную передачу CNN 42 в подсети 2, при помощи данных от
CNN 41.
Рисунок D.27 - Реконфигурация путей передачи
с двойными авариями CNN
з)
Двойные аварии CNN и связи
На рисунке D.28, в случае аварии CNN в подсети 1 и другой аварии связи в подсети 2:
CNN 31 выполняет запасную передачу CNN 21 в подсети 1, при помощи данных от
CNN 22,
CNN 32 выполняет запасную передачу CNN 42 и 52 в подсети 2, при помощи данных
от CNN 41 и 51,
CNN 42 выполняет запасную передачу CNN 12, 22 и 32 в подсети 2, при помощи
данных от CNN 11, 22 и 31.
Рисунок D.28 - Реконфигурация путей передач с двойными авариями связи и
CNN
е)
Двойные аварии CNN и связи в обеих подсетях
На рисунке D.29, в случае аварии CNN в подсети 1 и другой аварии связи в подсети 2;
CNN 32 выполняет запасную передачу CNN 22 в подсети 2, при помощи данных от
CNN 21,
112
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
CNN 41 выполняет запасную передачу CNN 51 в подсети 1, при помощи данных от
CNN 52,
CNN 51 выполняет запасную передачу CNN 11, 21, 31 и 41 в подсети 1, при помощи
данных от CNN 12, 21, 32 и 42.
Рисунок D.29 - Реконфигурация путей передачи с двойными авариями связи и
CNN
D.5. 3 Восстановление сети
В случае, если аварии связи или CNN восстановлены, когда CNN в обеих сторонах
находит ошибки, чтобы вернуться в нормальное состояние. Как правило, CNN удаляют
контроль маршрут обхода от мест ошибки, затем перезапускают нормальное
функционирование в обеих из подсетей.
Библиография
[1] IETF RFC 768, User Datagram Protocol, disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc768.txt>
[2] IETF RFC 791, Internet Protocol, disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc769.txt>
[3] IETF RFC 792, Internet Control Message Protocol, disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc792.txt>
[4] IETF RFC 793, Transmission Control Protocol, disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc793.txt>
[5] IETF RFC 826, An Ethernet Address Resolution Protocol: Or Converting Network
Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware, disponible à
l’adresse suivante: <http://www.ietf.org/rfc/rfc826.txt>
[6] IETF RFC 854, TELNET Protocol specification, disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc854.txt>
[7] IETF RFC 959, File Transfer Protocol (FTP), disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc959.txt>
113
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
[8] IETF RFC 1034, Domain Names – Concepts and Facilities, disponible à l’adresse
suivante: <http://www.ietf.org/rfc/rfc1034.txt>
[9] IETF RFC 1035, Domain Names – Implementation and Specification, disponible à
l’adresse suivante: <http://www.ietf.org/rfc/rfc1035.txt>
[10] IETF RFC 1112, Host Extensions for IP Multicasting, disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc1112.txt>
[11] IETF RFC 1122, Requirements for Internet Hosts – Communication Layers, disponible
à l’adresse suivante: <http://www.ietf.org/rfc/rfc1122.txt>
[12] IETF RFC 1166, Internet Numbers, disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc1166.txt>
[13] IETF RFC 1213, Management Information Base for Network Management of TCP/IPbased
internets: MIB-II, disponible à l’adresse suivante: <http://www.ietf.org/rfc/rfc1213.txt>
[14] IETF RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and
Analysis, disponible à l’adresse suivante: <http://www.ietf.org/rfc/rfc1305.txt>
[15] IETF RFC 1350, THE TFTP Protocol (REVISION 2), disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc1350.txt>
[16] IETF RFC 1361, Simple Network Time Protocol (SNTP), disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc1361.txt>
[17] IETF RFC 1901, Introduction to Community-based SNMPv2 disponible à l’adresse
suivante: http://www.ietf.org/rfc/rfc1901.txt – 248 – IEC 61375-3-4:2014 © IEC 2014
[18] IETF RFC 1905, Protocol Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2), disponible à l’adresse suivante: <http://www.ietf.org/rfc/rfc1905.txt>
[19] IETF RFC 1906, Transport Mappings for Version 2 of the Simple Network Management
Protocol (SNMPv2), disponible à l’adresse suivante: <http://www.ietf.org/rfc/rfc1906.txt>
[20] IETF RFC 1918, Address Allocation for Private Internets, disponible à l’adresse
suivante: <http://www.ietf.org/rfc/rfc1918.txt>
[21] IETF RFC 2131, Dynamic Host Configuration Protocol, disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc2131.txt>
[22] IETF RFC 2132, DHCP Options and BOOTP Vendor Extensions, disponible à l’adresse
suivante: <http://www.ietf.org/rfc/rfc2132.txt>
[23] IETF RFC 2236, Internet Group Management Protocol, Version 2, disponible à l’adresse
suivante: <http://www.ietf.org/rfc/rfc2236.txt>
[24] IETF RFC 2365, Administratively Scoped IP Multicast, disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc2365.txt>
[25] IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers, disponible à l’adresse suivante: <http://www.ietf.org/rfc/rfc2474.txt>
[26] IETF RFC 2544, Benchmarking Methodology for Network Interconnect Devices,
disponible à l’adresse suivante: <http://www.ietf.org/rfc/rfc2544.txt>
[27] IETF RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, disponible à l’adresse
suivante: <http://www.ietf.org/rfc/rfc2616.txt>
[28] IETF RFC 3022, Traditional IP Network Address Translator (Traditional NAT),
disponible à l’adresse suivante: <http://www.ietf.org/rfc/rfc3022.txt>
[29] IETF RFC 3046, DHCP Relay Agent Information Option,disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc3046.txt>
[30] IETF RFC 3203, DHCP reconfigure extension, disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc3203.txt>
[31] IETF RFC 3376, Internet Group Management Protocol, Version 3, disponible à l’adresse
suivante: <http://www.ietf.org/rfc/rfc3376.txt>
114
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
[32] IETF RFC 3768, Virtual Router Redundancy Protocol (VRRP), disponible à l’adresse
suivante: <http://www.ietf.org/rfc/rfc3768.txt>
[33] IETF RFC 4251, The Secure Shell (SSH) Protocol Architecture disponible à l’adresse
suivante: <http://www.ietf.org/rfc/rfc4251.txt>
[34] IETF RFC 4541, Considerations for Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Snooping Switches,disponible à l’adresse suivante:
<http://www.ietf.org/rfc/rfc4541.txt>
УДК 629.4.027.11(430)
МКС 45.040
Ключевые слова: поездные сети связи, информационные технологии, электронное
железнодорожное оборудование
115
СТ РК IEC 61375-3-4_____
(проект, редакция 1)
РАЗРАБОТЧИК
АО «Казахская академия транспорта и коммуникаций им. М.Тынышпаева»
Научный сотрудник, к.т.н., доцент
А.Алижан
Научный сотрудник
И.Жайсан
-
116