Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 76

ITU - Lĩnh vực tiêu chuẩn hóa viễn thông Tài liệu tạm thời 066 (PLEN)

NHÓM NGHIÊN CỨU 15

Geneva, 15-26 tháng 10 năm 2001

Câu hỏi: Q14 / 15

NGUỒN *: Trình soạn thảo G.7712 / Y.1703

TITLE: Bản thảo sửa đổi G.7712 / Y.1703 (ví dụ: G.dcn), Phiên bản 1.1
__________________

TD này cung cấp phiên bản 1.1 cho Bản sửa đổi dự thảo của G.7712 / Y.1703 (ví dụ :G.dcn).

* Liên hệ: Carmine Daloia ĐT: +1 732 949 5369


Lucent Technologies Số fax: +1 732 949 3210
E-mail: daloia@lucent.com

Chú ý:Đây không phải là một ấn phẩm được cung cấp cho công chúng, mà là một Tài liệu ITU-T nội bộ chỉ dành cho các Quốc gia
Thành viên của ITU, các Thành viên và Cộng sự của ITU-T cũng như các nhân viên và cộng tác viên tương ứng của họ trong công
việc liên quan đến ITU của họ . Nó sẽ không được cung cấp cho và sử dụng bởi bất kỳ cá nhân hoặc tổ chức nào khác mà không có
sự đồng ý trước bằng văn bản của ITU-T.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
2

ITU-T DỰ THẢO KHUYẾN NGHỊ MỚI G.7712 / Y.1703

KIẾN TRÚC VÀ ĐẶC ĐIỂM KỸ THUẬT CỦA MẠNG TRUYỀN THÔNG DỮ LIỆU

Bản tóm tắt


Khuyến nghị này xác định các yêu cầu về kiến trúc đối với Mạng truyền thông dữ liệu (DCN) có
thể hỗ trợ truyền thông quản lý phân tán liên quan đến Mạng quản lý viễn thông (TMN), truyền
thông báo hiệu phân tán liên quan đến Mạng truyền tải chuyển mạch tự động (ASTN) và các thông
tin liên lạc phân tán khác (ví dụ: , Orderwire hoặc Voice Communications, Tải xuống phần mềm).
Kiến trúc DCN coi các mạng chỉ IP, chỉ OSI và hỗn hợp (tức là hỗ trợ cả IP và OSI). Việc tương tác
giữa các bộ phận của DCN chỉ hỗ trợ IP, các bộ phận chỉ hỗ trợ OSI và các bộ phận hỗ trợ cả IP và
OSI cũng được chỉ định.
Các ứng dụng khác nhau (ví dụ: TMN, ASTN, v.v.) yêu cầu một mạng truyền thông dựa trên gói để
vận chuyển thông tin giữa các thành phần khác nhau. Ví dụ, TMN yêu cầu một mạng truyền thông,
được gọi là Mạng Truyền thông Quản lý (MCN) để vận chuyển các thông điệp quản lý giữa các
thành phần TMN (ví dụ: thành phần NEF và thành phần OSF). ASTN yêu cầu một mạng truyền
thông, được gọi là Mạng Truyền thông Báo hiệu (SCN) để vận chuyển các bản tin báo hiệu giữa các
thành phần ASTN (ví dụ: các thành phần CC). Khuyến nghị này chỉ định các chức năng giao tiếp
dữ liệu có thể được sử dụng để hỗ trợ một hoặc nhiều mạng truyền thông của ứng dụng.
Các chức năng truyền thông dữ liệu được cung cấp trong khuyến nghị này hỗ trợ các dịch vụ mạng
không cần kết nối. Các chức năng bổ sung có thể được thêm vào trong các phiên bản tương lai của
khuyến nghị này để hỗ trợ các dịch vụ mạng hướng kết nối.
Nguồn và lịch sử
Khuyến nghị này là một phần của bộ Khuyến nghị bao gồm các mạng lưới giao thông.

Tài liệu Lịch sử


Phát hành Ghi chú
1,0 Kết quả của cuộc họp Q14 / 15 tháng 10 năm 2001
1.1 Kết quả của cuộc họp Q14 / 15 tháng 4 năm 2002

Từ khóa
Mạng Truyền thông Dữ liệu, Giao thức Internet (IP), Giao diện Hệ thống Mở (OSI).

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
3

NỘI DUNG

1 Phạm vi 4
2 Tài liệu tham khảo 4
3 Thuật ngữ và định nghĩa 5
4 chữ viết tắt 7
5 quy ước 9
6 Đặc điểm DCN 10
7 Kiến trúc và yêu cầu chức năng của DCN 29
phụ lục A 40
PHỤ LỤC B 44
PHỤ LỤC Các hạn chế của chức năng liên kết OSPF / IntISIS................................................... 37
PHỤ LỤC II. 40

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
4

1 Phạm vi
Khuyến nghị này xác định các yêu cầu về kiến trúc đối với Mạng truyền thông dữ liệu (DCN) có
thể hỗ trợ truyền thông quản lý phân tán liên quan đến Mạng quản lý viễn thông (TMN), truyền
thông báo hiệu phân tán liên quan đến Mạng truyền tải chuyển mạch tự động (ASTN) và các thông
tin liên lạc phân tán khác (ví dụ: , Orderwire hoặc Voice Communications, Tải xuống phần mềm).
Kiến trúc DCN coi các mạng chỉ IP, chỉ OSI và hỗn hợp (tức là hỗ trợ cả IP và OSI). Việc tương tác
giữa các bộ phận của DCN chỉ hỗ trợ IP, các bộ phận chỉ hỗ trợ OSI và các bộ phận hỗ trợ cả IP và
OSI cũng được chỉ định.
DCN cung cấp chức năng Lớp 1 (vật lý), Lớp 2 (liên kết dữ liệu) và Lớp 3 (mạng) và bao gồm chức
năng định tuyến / chuyển mạch được kết nối với nhau thông qua các liên kết. Các liên kết này có
thể được thực hiện trên nhiều giao diện khác nhau, bao gồm giao diện Mạng diện rộng (WAN), giao
diện Mạng cục bộ (LAN) và Kênh điều khiển nhúng (ECC).
Các ứng dụng khác nhau (ví dụ: TMN, ASTN, v.v.) yêu cầu một mạng truyền thông dựa trên gói để
vận chuyển thông tin giữa các thành phần khác nhau. Ví dụ, TMN yêu cầu một mạng truyền thông,
được gọi là Mạng Truyền thông Quản lý (MCN) để vận chuyển các thông điệp quản lý giữa các
thành phần TMN (ví dụ: thành phần NEF và thành phần OSF). ASTN yêu cầu một mạng truyền
thông, được gọi là Mạng Truyền thông Báo hiệu (SCN) để vận chuyển các bản tin báo hiệu giữa các
thành phần ASTN (ví dụ: các thành phần CC). Khuyến nghị này chỉ định các chức năng giao tiếp
dữ liệu có thể được sử dụng để hỗ trợ một hoặc nhiều mạng truyền thông của ứng dụng.
Các chức năng truyền thông dữ liệu được cung cấp trong khuyến nghị này hỗ trợ các dịch vụ mạng
không cần kết nối. Các chức năng bổ sung có thể được thêm vào trong các phiên bản tương lai của
khuyến nghị này để hỗ trợ các dịch vụ mạng hướng kết nối.

2Tài liệu tham khảo


Các Khuyến nghị ITU-T sau đây và các tài liệu tham khảo khác bao gồm các điều khoản, thông qua
việc tham khảo trong văn bản này, cấu thành các điều khoản của Khuyến nghị này. Tại thời điểm
xuất bản, các ấn bản được chỉ định là hợp lệ. Tất cả các Khuyến nghị và các tài liệu tham khảo khác
có thể được sửa đổi; do đó, tất cả những người sử dụng Khuyến nghị này được khuyến khích điều
tra khả năng áp dụng phiên bản mới nhất của Khuyến nghị và các tài liệu tham khảo khác được liệt
kê bên dưới. Danh sách các Khuyến nghị ITU-T hiện có hiệu lực thường xuyên được xuất bản.
 ITU-T G.7070 - Giao diện nút mạng cho hệ thống phân cấp kỹ thuật số đồng bộ.
 ITU-T G.7090 - Giao diện nút mạng cho mạng truyền tải quang.
 ITU-T G.783 - Đặc điểm của khối chức năng thiết bị phân cấp kỹ thuật số đồng bộ (SDH)
 ITU-T G.784 - Quản lý phân cấp kỹ thuật số đồng bộ (SDH)
 ITU-T G.798 - Đặc điểm của Khối chức năng thiết bị phân cấp mạng lưới truyền tải quang
(OTN).
 ITU-T G.8070 - Yêu cầu đối với mạng truyền tải được chuyển mạch tự động (ASTN)
 ITU-T G.872 - Kiến trúc của mạng truyền tải quang.
 ITU-T G.874 - Quản lý mạng truyền tải quang (OTN)
 ITU-T G.8080 - Kiến trúc cho mạng quang chuyển mạch tự động (ASON)
 ITU-T G.7710 - Yêu cầu quản lý thiết bị chung

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
5

 ITU-T M.3010 - Nguyên tắc cho mạng quản lý viễn thông


 ITU-T M.3013 - Cân nhắc đối với mạng quản lý viễn thông
 ITU-T M.3016 - Tổng quan về bảo mật TMN
 ITU-T Q.811 - Cấu hình giao thức lớp dưới cho giao diện Q3 và X.
 ITU-T X.263 - Công nghệ thông tin - Nhận dạng giao thức trong Lớp mạng
 IETF RFC 0791 - Giao thức Internet Đặc điểm kỹ thuật giao thức chương trình Internet
DARPA - Tháng 9 năm 1981
 IETF RFC 792 - Giao thức thông báo điều khiển Internet - tháng 9 năm 1981
 IETF RFC 894 - Một tiêu chuẩn để truyền biểu đồ IP qua mạng Ethernet - tháng 4 năm
1984
 IETF RFC 826 - Giao thức phân giải địa chỉ Ethernet - tháng 11 năm 1982
 IETF RFC 1195 - Sử dụng OSI IS-IS để định tuyến trong TCP / IP và Môi trường kép -
Tháng 12 năm 1990
 IETF RFC 1122 - Yêu cầu đối với Máy chủ Internet - Tháng 10 năm 1989
 IETF RFC 1172 - Tùy chọn cấu hình ban đầu của giao thức điểm-điểm - tháng 7 năm 1990
 IETF RFC 1332 - Giao thức kiểm soát giao thức Internet PPP (IPCP) - Tháng 5 năm 1992
 IETF RFC 1377 - Giao thức kiểm soát lớp mạng PPP OSI (OSINLCP) - Tháng 11 năm
1992
 IETF RFC 1661 - Giao thức điểm-điểm (PPP) - tháng 7 năm 1994
 IETF RFC 1662 - PPP trong khung giống HDLC - tháng 7 năm 1994
 IETF RFC 1812 - Yêu cầu đối với bộ định tuyến IP phiên bản 4 - tháng 6 năm 1995
 IETF RFC 2328 - Phiên bản OSPF 2 - Tháng 4 năm 1998
 Đặc điểm kỹ thuật IETF RFC 2460 - Giao thức Internet, Phiên bản 6 (IPv6) - Tháng 12
năm 1998
 IETF RFC 2463 - Giao thức Thông báo Điều khiển Internet (ICMPv6) cho Đặc điểm kỹ
thuật Giao thức Internet Phiên bản 6 (IPv6) - Tháng 12 năm 1998
 IETF RFC 2472 - IP phiên bản 6 qua PPP - tháng 12 năm 1998
 IETF RFC 2740 - OSPF cho IPv6 - tháng 12 năm 1999
 IETF RFC 2784 - Đóng gói định tuyến chung (GRE)
 ISO / IEC 10589 - Công nghệ thông tin - Viễn thông và trao đổi thông tin giữa các hệ
thống - Hệ thống trung gian đến Hệ thống trung gian giao thức trao đổi thông tin định tuyến
nội miền để sử dụng cùng với giao thức cung cấp Dịch vụ mạng không chế độ kết nối (ISO
8473) - 1992

3 Điều khoản và định nghĩa


Khuyến nghị này sử dụng các thuật ngữ được định nghĩa trong Khuyến nghị G.709:
3.1 Đơn vị dữ liệu kênh quang (ODUk)

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
6

3.2 Đơn vị vận chuyển kênh quang (OTUk)


3,3 Tín hiệu quang trên đầu (OOS)
Khuyến nghị này sử dụng các thuật ngữ được xác định trong Khuyến nghị G.784:
3,4 Kênh truyền thông dữ liệu (DCC)
Khuyến nghị này sử dụng các thuật ngữ được xác định trong Khuyến nghị G.8070:
3.5 Mạng lưới giao thông được chuyển mạch tự động (ASTN)
3.6 Mạng - Giao diện mạng (NNI)
3.7 Người dùng - Giao diện mạng (UNI)
Khuyến nghị này sử dụng các thuật ngữ được xác định trong Khuyến nghị G.8080:
3.8 Bộ điều khiển cuộc gọi (CallC)
3,9 Bộ điều khiển kết nối (CC)
3,10 Giao diện bộ điều khiển kết nối (CCI)
3,11 Bộ điều khiển mạng con (SNCr)
Khuyến nghị này sử dụng các thuật ngữ được xác định trong Khuyến nghị G.874:
3,10 Kênh truyền thông chung (GCC)
3,11 Quản lý chung Chi phí Truyền thông (COMMS OH)
Khuyến nghị này sử dụng các thuật ngữ được xác định trong Khuyến nghị G.7710:
3,12 Mạng quản lý X
3,13 Mạng con quản lý X
Khuyến nghị này sử dụng các thuật ngữ được xác định trong Khuyến nghị G.872:
3,14 Mạng truyền tải quang (OTN)
Khuyến nghị này sử dụng các thuật ngữ được định nghĩa trong Khuyến nghị M.3010:
3,15 Thiết bị Thích ứng (AD)
3,16 Chức năng Truyền thông Dữ liệu (DCF)
3,17 Thiết bị dàn xếp (MD)
3,18 Phần tử mạng (NE)
3,19 Chức năng phần tử mạng (NEF)
3,20 Hệ điều hành (OS)
3,21 Chức năng Hệ thống Hoạt động (OSF)
3,22 Giao diện Q
3,23 Chức năng dịch
3,24 Chức năng máy trạm (WSF)
Khuyến nghị này sử dụng các thuật ngữ được xác định trong Khuyến nghị M.3013:

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
7

3,25 Chức năng Truyền thông Tin nhắn (MCF)


Khuyến nghị này xác định các thuật ngữ sau:
3,26 Mạng Truyền thông Dữ liệu (DCN):DCN là mạng hỗ trợ chức năng Lớp 1 (vật lý), Lớp 2
(liên kết dữ liệu) và Lớp 3 (mạng). Một DCN có thể được thiết kế để hỗ trợ vận chuyển thông tin
liên lạc quản lý phân tán liên quan đến TMN, thông tin liên lạc báo hiệu phân tán liên quan đến
ASTN, và các thông tin liên lạc hoạt động khác (ví dụ: giao tiếp bằng dây lệnh / thoại, tải xuống
phần mềm, v.v.).
3,27 Kênh điều khiển nhúng (ECC):ECC cung cấp một kênh hoạt động hợp lý giữa các NE.
Kênh vật lý hỗ trợ ECC là công nghệ cụ thể. Ví dụ về các kênh vật lý hỗ trợ ECC là; một kênh DCC
trong SDH, kênh GCC trong OTN OTUk / ODUk hoặc kênh COMMS OH trong OTN OOS.

4 Viết tắt
Khuyến nghị này sử dụng các từ viết tắt sau:
ADAdaptation Device
Giao thức phân giải địa chỉ ARP
Mạng quang chuyển mạch tự động ASON
Mạng lưới vận tải chuyển mạch tự động ASTNA
ATMAsynchronous Transfer Mode
Bộ điều khiển cuộc gọi
Bộ điều khiển kết nối CCC
Giao diện bộ điều khiển kết nối CCIC
CLN Giao thức lớp mạng không kết nối
CLNDịch vụ lớp mạng không kết nối
COMMS OHGeneral Management Communications Overhead
Kênh truyền thông DCCData
Chức năng truyền dữ liệu DCFData
Mạng truyền thông DCNData
DFD Don't Fragment
Kênh điều khiển ECCEmbedded
Chức năng quản lý thiết bị EMFE
E-NNI NNI bên ngoài
Hệ thống ESEnd
Hệ thống ES ISEnd đến Hệ thống trung gian
Kênh truyền thông chung của GCC
Phần tử mạng GNEGateway
Đóng gói định tuyến GREGeneric
Kiểm soát liên kết dữ liệu cấp độ cao HDLCH

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
8

ICMPInternet Control Message Protocol


IDIdentifier
IIHISIS xin chào
Giao thức IPInternetwork
Giao thức IPv4Internetwork phiên bản 4
IPv6Internetwork Protocol phiên bản 6
Giao thức kiểm soát giao thức IPCPInternet
I-NNIII nội bộ NNI
Hệ thống trung gian được tích hợp vào hệ thống trung gian
Hệ thống ISInter Instant
ISDNIntegrated Services Mạng kỹ thuật số
Hệ thống trung gian ISHISO 9542 Xin chào
Hệ thống ngay lập tức đến Hệ thống trung gian
Chức năng IWFInterworking
Mạng LANLocal
Kênh D-Quy trình truy cập liên kết LAP
Mạng truyền thông LCNLocal
LSPLink State PacketĐơn vị dữ liệu giao thức
Kiểm soát truy cập MACMedia
Chức năng truyền thông tin nhắn tin MCF
Mạng truyền thông quản lý MCN
Thiết bị MDMediation
MTUMaximum Trans iđơn vị nhiệm vụ
Phần tử NENetwork
Hàm phần tử mạng NEF
NNINetwork - Giao diện mạng
Đơn vị dữ liệu kênh ODUkOptical
Tín hiệu trên không OOSOTM
Hệ thống OSOperations
Kênh giám sát OSCOptical
Chức năng hệ thống OSFOperations
Giao diện hệ thống OSIOpen
Giao thức kiểm soát lớp mạng OSINLCPOSI
OSPFOpen Đường dẫn ngắn nhất Đầu tiên
Mô-đun truyền tải quang học OTMOptical

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
9

OTNOptical Transport Network


Đơn vị vận chuyển kênh quang học OTUkOptical
Điểm truy cập dịch vụ mạng NSAP
PDU Packet Giao thức Đơn vị dữ liệu
Giao thức PPPPoint-to-Point
RFC Yêu cầu Bình luận
Mạng truyền thông SCNSignaling
Cấu trúc phân cấp kỹ thuật số không đồng bộ SDHS
Bộ điều khiển SNCrSubnetwork
SPSegmentation được phép
Giao thức kiểm soát truyền dẫn TCPT
Chức năng dịch TFT
Giá trị độ dài TLVType
Mạng quản lý viễn thông TMNT
Phần tử mạng TNETransport
UNIUser to Network Interface
Mạng diện rộng WAN
Trạm WSWork
Chức năng WSFWork Station
Mạng con quản lý xMSX

5 Công ước
Các quy ước sau được sử dụng trong suốt khuyến nghị này:
DCN hỗn hợp: Một DCN hỗn hợp hỗ trợ nhiều giao thức lớp mạng (ví dụ: OSI và IPv4). Có thể
trong một DCN hỗn hợp, đường dẫn giữa hai thực thể giao tiếp (ví dụ: một hệ điều hành và một NE
được quản lý) sẽ đi qua một số phần chỉ hỗ trợ một giao thức lớp mạng (ví dụ: OSI) và các phần
khác chỉ hỗ trợ một lớp mạng khác giao thức (ví dụ: IPv4). Để cung cấp thông tin liên lạc giữa các
thực thể như vậy, một giao thức lớp mạng nên được gói gọn vào giao thức lớp mạng khác tại ranh
giới của các phần đó hỗ trợ các giao thức lớp mạng khác nhau.
DCN chỉ dành cho OSI: DCN chỉ dành cho OSI chỉ hỗ trợ CLNP làm giao thức lớp mạng. Do
đó, đường dẫn end-to-end giữa hai thực thể giao tiếp (ví dụ: một hệ điều hành và một NE được quản
lý) sẽ hỗ trợ CLNP và việc đóng gói giao thức lớp mạng này vào một giao thức lớp mạng khác là
không cần thiết để hỗ trợ các giao tiếp như vậy.
DCN chỉ IPv4: DCN chỉ IPv4 chỉ hỗ trợ IPv4 làm giao thức lớp mạng. Do đó, đường dẫn end-to-
end giữa hai thực thể giao tiếp (ví dụ: một hệ điều hành và một NE được quản lý) sẽ hỗ trợ IPv4 và
việc đóng gói giao thức lớp mạng này vào một giao thức lớp mạng khác là không cần thiết để hỗ trợ
các giao tiếp như vậy.
DCN chỉ IPv6: DCN chỉ IPv6 chỉ hỗ trợ IPv6 làm giao thức lớp mạng. Do đó, đường dẫn end-to-
end giữa hai thực thể giao tiếp (ví dụ: một hệ điều hành và một NE được quản lý) sẽ hỗ trợ IPv6 và

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
10

việc đóng gói giao thức lớp mạng này vào một giao thức lớp mạng khác là không cần thiết để hỗ trợ
các giao tiếp như vậy.

Đặc điểm 6DCN


Các ứng dụng khác nhau (ví dụ: TMN, ASTN, v.v.) yêu cầu một mạng truyền thông dựa trên gói để
vận chuyển thông tin giữa các thành phần khác nhau. Ví dụ, TMN yêu cầu một mạng truyền thông,
được gọi là Mạng Truyền thông Quản lý (MCN) để vận chuyển các thông điệp quản lý giữa các
thành phần TMN (ví dụ: thành phần NEF và thành phần OSF). ASTN yêu cầu một mạng truyền
thông, được gọi là Mạng Truyền thông Báo hiệu (SCN) để vận chuyển các bản tin báo hiệu giữa các
thành phần ASTN (ví dụ: các thành phần CC). Khuyến nghị này chỉ định các chức năng giao tiếp
dữ liệu có thể được sử dụng để hỗ trợ một hoặc nhiều mạng truyền thông của ứng dụng.
Hình 6-1 minh họa các ứng dụng ví dụ có thể được hỗ trợ qua DCN. Mỗi ứng dụng có thể được hỗ
trợ trên các DCN riêng biệt hoặc trên cùng một DCN tùy thuộc vào thiết kế mạng.

Management Signalling Other Applications


Applications Applications (e.g., Software Download)
(e.g., TMN) (e.g., ASTN)

Management Signalling Other


Communications Communications Communications

DCN

HÌNH 6-1
Các ứng dụng mẫu được DCN hỗ trợ

Khái niệm DCN là một tập hợp các tài nguyên để hỗ trợ việc chuyển giao thông tin giữa các thành
phần phân tán. Như đã thảo luận ở trên, các ví dụ về truyền thông phân tán có thể được hỗ trợ bởi
DCN là truyền thông quản lý phân tán liên quan đến TMN và truyền thông báo hiệu phân tán liên
quan đến ASTN. Trong trường hợp DCN hỗ trợ truyền thông quản lý phân tán, các thành phần được
phân phối là các thành phần TMN (NE, AD, OS, MD và WS có chứa các chức năng TMN như
OSF, TF, NEF, WSF). Các khuyến nghị M.3010 và M.3013 cung cấp thêm thông số kỹ thuật cho
các chức năng TMN. Trong trường hợp DCN hỗ trợ truyền thông báo hiệu phân tán, các thành phần
phân tán là các thành phần ASTN (NE chứa các chức năng ASTN SNCr). Khuyến nghị G.8070 và
G.
Một số công nghệ viễn thông có thể hỗ trợ các chức năng DCN như chuyển mạch kênh, chuyển
mạch gói, LAN, ATM, SDH và OTN. Các khía cạnh quan trọng của DCN là chất lượng dịch vụ, tốc
độ truyền thông tin và tính đa dạng của định tuyến để hỗ trợ các yêu cầu hoạt động cụ thể của
truyền thông phân tán được hỗ trợ trên DCN (ví dụ: truyền thông quản lý phân tán, truyền thông
báo hiệu phân tán).

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
11

Mục tiêu của đặc tả giao diện là đảm bảo trao đổi dữ liệu có ý nghĩa giữa các thiết bị được kết nối
với nhau thông qua DCN để thực hiện một chức năng nhất định (ví dụ: chức năng TMN, chức năng
ASTN). Giao diện được thiết kế để đảm bảo tính độc lập của loại thiết bị hoặc nhà cung cấp. Điều
này yêu cầu các giao thức truyền thông tương thích và biểu diễn dữ liệu tương thích cho các thông
báo, bao gồm các định nghĩa thông báo chung tương thích cho các chức năng quản lý TMN và chức
năng điều khiển ASTN.
DCN chịu trách nhiệm cung cấp giao tiếp tương thích ở lớp mạng (Lớp 3), lớp liên kết dữ liệu (Lớp
2) và lớp vật lý (Lớp 1).
Cần xem xét các giao diện để tương thích với các phương tiện vận chuyển dữ liệu hiệu quả nhất có
sẵn cho từng phần tử mạng riêng lẻ [ví dụ: mạch thuê, kết nối chuyển mạch kênh, kết nối chuyển
mạch gói, Hệ thống tín hiệu số 7, Các kênh truyền thông nhúng của SDH, Các kênh D- và B của
mạng truy cập OTN và ISDN].
Khuyến nghị này chỉ định ba lớp thấp hơn để giao tiếp dữ liệu và do đó bất kỳ hoạt động liên thông
nào giữa các giao thức trong ba lớp dưới. Sự liên kết như vậy được cung cấp bởi Chức năng Truyền
thông Dữ liệu (DCF). Các ví dụ về hoạt động liên thông như vậy được minh họa trong Hình 6-2.
Lưu ý rằng việc liên kết như vậy không chấm dứt các giao thức Lớp 3. Một ví dụ là liên kết giữa
các lớp vật lý khác nhau thông qua giao thức Lớp 2 chung (ví dụ: bắc cầu các khung MAC từ giao
diện LAN đến ECC). Một ví dụ khác là liên kết giữa các giao thức lớp liên kết dữ liệu khác nhau
thông qua một giao thức lớp 3 chung (ví dụ: định tuyến các gói IP từ giao diện LAN đến ECC). Ví
dụ thứ ba được minh họa trong Hình 6-2,
Loại thông tin được vận chuyển giữa các thành phần được phân phối phụ thuộc vào loại giao diện
được hỗ trợ giữa các thành phần. Một DCN hỗ trợ truyền thông quản lý phân tán liên quan đến
TMN cần hỗ trợ việc vận chuyển thông tin được liên kết với các giao diện TMN được xác định
trong Khuyến nghị M.3010. Một DCN hỗ trợ truyền thông báo hiệu phân tán liên quan đến ASTN
cần hỗ trợ việc vận chuyển thông tin liên quan đến các giao diện ASTN được xác định trong
Khuyến nghị G.8070.

Layer 2 (MAC)

Layer 1 (ECC) Layer 1 (LAN)

Layer 3 (IP)

Layer 2 (PPP) Layer 2 (MAC)

Layer 1 (ECC) Layer 1 (LAN)

Layer 3 (OSI)
Layer 3 (IP)

Layer 2 (LAPD) Layer 2 (MAC)

Layer 1 (ECC) Layer 1 (LAN)

HÌNH 6-2
Ví dụ về kết nối DCN

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
12

Ứng dụng 6.1TMN


TMN yêu cầu một mạng truyền thông, được gọi là Mạng Truyền thông Quản lý (MCN) để vận
chuyển các thông điệp quản lý giữa các thành phần TMN (ví dụ: thành phần NEF và thành phần
OSF). Hình 6-3 minh họa mối quan hệ ví dụ của MCN và TMN. Các giao diện giữa các phần tử
khác nhau (ví dụ: OS, WS, NE) và MCN như được minh họa trong Hình 6-3 là logic và có thể được
hỗ trợ trên một giao diện MCN vật lý hoặc nhiều giao diện MCN.
Hình 6-4 minh họa một ví dụ về việc triển khai vật lý của một MCN hỗ trợ truyền thông quản lý
phân tán. Tùy thuộc vào sự lựa chọn triển khai của MCN, các phần tử vật lý có thể hỗ trợ bất kỳ sự
kết hợp nào của giao diện ECC, giao diện LAN và giao diện WAN. Hình 6-4 cũng minh họa các
loại khối chức năng của mặt phẳng quản lý có thể được hỗ trợ trong các phần tử vật lý khác nhau.
Tham khảo Khuyến nghị M.3010 và M.3013 để biết thông số kỹ thuật chi tiết liên quan đến các
khối chức năng quản lý này. Chức năng Truyền thông Dữ liệu (DCF) là một phần của mỗi phần tử
vật lý và cung cấp các chức năng truyền thông dữ liệu.

TMN-A Operations Operations TMN-B


System System

Q/X/F Q/X/F

F Management X X Management F
Work X-Mediation Work
Communication Communication
Station Device Station
Network Network

Q Q

Q-Mediation Q-Mediation
Device Device

Q Q

F Management X X Management F
Work X-Mediation Work
Communication Communication
Station Device Station
Network Network

Q Q/X/F Q Q/X/F Q Q/X/F Q Q/X/F

Q Network Q Network Q Network Q Network


Adaptor Element Adaptor Element Adaptor Element Adaptor Element

HÌNH 6-3
Mối quan hệ mẫu của giao diện TMN và MCN

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
13

OS
OS
OSF
OSF
WS
LAN
WSF
WAN Interface

WAN

WAN Interface

MD

TF
NEF ECC NEF
LAN
NE NE
WS

WSF
NE
LAN
TF
q
NEF ECC NEF
ECC
ECC
NE NE
NEF
NEF NEF

NE NE

Data Communication
Function (DCF)

Physical Element
Function Block

HÌNH 6-4
Ví dụ về triển khai vật lý của MCN hỗ trợ TMN

Kiến trúc mạng con quản lý 6.1.1X


Trong Hình 6-5, cần lưu ý một số điểm liên quan đến kiến trúc của Mạng con quản lý X (xMS):
- Nhiều NE tại một địa điểm: Nhiều NE SDH hoặc OTN có thể định địa chỉ có thể xuất hiện
tại một địa điểm nhất định. Ví dụ, trong Hình 6-5 NEE và NEG có thể được sắp xếp tại một
vị trí thiết bị duy nhất.

- SDH / OTN NE và chức năng giao tiếp của chúng: Chức năng truyền thông tin của SDH
hoặc OTN NE kết thúc (theo nghĩa của các lớp giao thức thấp hơn), định tuyến hoặc xử lý
các thông điệp trên ECC hoặc được kết nối qua giao diện bên ngoài.

i) Tất cả các NE được yêu cầu chấm dứt ECC. Điều này có nghĩa là mỗi NE phải có
khả năng thực hiện các chức năng của hệ thống cuối OSI hoặc máy chủ IP.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
14

ii) Các NE cũng có thể được yêu cầu định tuyến các bản tin ECC giữa các cổng theo
thông tin điều khiển định tuyến được lưu giữ trong NE. Điều này có nghĩa là
một NE cũng có thể được yêu cầu để thực hiện các chức năng của hệ thống
trung gian OSI hoặc bộ định tuyến IP.
- Thông tin liên lạc giữa các địa điểm SDH / OTN: Liên kết thông tin liên lạc giữa các địa
điểm hoặc giữa các văn phòng giữa các NE SDH / OTN có thể được hình thành từ các SDH
/ OTN ECC.

- Truyền thông nội bộ SDH / OTN: Trong một trang web cụ thể, các NE SDH / OTN có thể
giao tiếp qua ECC nội bộ hoặc qua Mạng truyền thông cục bộ (LCN). Hình 6-5 minh họa
cả hai trường hợp của giao diện này.

CHÚ THÍCH - Một LCN được tiêu chuẩn hóa để giao tiếp giữa các phần tử mạng được sắp xếp đã
được đề xuất như một giải pháp thay thế cho việc sử dụng ECC. LCN có khả năng sẽ được sử dụng
như một mạng thông tin liên lạc trang web chung phục vụ các NEs SDH, OTN và không SDH /
OTN (NNE).
Telecommunications management network (TMN)

F
OS1

Q Q
F MDE Q OS2 F
MDA
X management
network (xMN)
Q Q Q Q domain

NNEA GNEA GNEE GNEG GNEJ

ECC ECC ECC ECC ECC ECC

F ECC
NEB NEC NEF NEH1 NEH2 NEK1 NEK2 NEM

LCN
... LCN
ECC ECC Non-ECC Non-ECC ECC
link link
NNEB x mgmt. NED NEI NEL
subnet-1 xMS-2 xMS-n

T1508870-92

Communications blocks (OS, MD, GNE, NE)

Communications links using standard Q-interface protocol


SDH/OTN ECC
LCN Local communications network
GNE Gateway network element (see 5.3.1)

NOTE – The designation "Q" is used in a generic sense.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
15

HÌNH 6-5
TMN, Mạng quản lý và Mô hình mạng con quản lý

6.1.1.1 Cơ quan quản lý mạng con


Hình 6-6 minh họa các cấu trúc liên kết MCN ví dụ như tuyến tính, vòng, lưới và hình sao sử dụng
ECC và / hoặc Mạng truyền thông cục bộ (LCN) (ví dụ: Ethernet LAN) như các liên kết vật lý kết
nối các Phần tử mạng. Hình 6-7 minh họa cách một Mạng con quản lý có thể được hỗ trợ trên mỗi
cấu trúc liên kết. Chung cho mỗi cấu trúc liên kết là Cổng kép (GNE1 và GNE2) cho phép truy cập
đáng tin cậy vào các NE trong Mạng con quản lý. Một khía cạnh chung khác đối với mỗi cấu trúc
liên kết ví dụ là mỗi cấu trúc liên kết cho phép nhiều đường dẫn đa dạng giữa bất kỳ NE nào trong
Mạng con quản lý và Hệ thống vận hành (OS).

LCN

NE1 NEA NEB NE C NE D NE2


ECC ECC ECC ECC

(Example Linear Topology)

ECC ECC ECC


NE1 NEB NEC NE2 NE1 NE2

ECC ECC
ECC ECC ECC ECC
LCN

NEA NED NEA NEB NEC NED

ECC
ECC ECC
ECC ECC
ECC ECC

NEE NEF NEG NEE NEF NEG


ECC ECC ECC ECC

(Example Ring Topology) (Example Mesh Topology)

NE1 NE2
ECC ECC

ECC
ECC
ECC ECC ECC
ECC

NEA NEB NEC NED

(Example Star Topology)

HÌNH 6-6
Cấu trúc liên kết mẫu

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
16

to/from OS to/from OS

LCN

GNE1 NEA NEB NE C NED GNE2


ECC ECC ECC ECC

S/OMS (Example Linear Topology)

to/from OS to/from OS to/from OS to/from OS

ECC ECC ECC


GNE1 NEB NEC GNE2 GNE1 GNE2

ECC ECC
ECC ECC ECC ECC
LCN

NEA NE D NEA NEB NEC NED

ECC
ECC ECC
ECC ECC
ECC ECC

NEE NEF NEG NEE NE F NEG


ECC ECC ECC ECC

S/OMS (Example Ring Topology) S/OMS (Example Mesh Topology)

to/from OS to/from OS

GNE1 GNE2
ECC ECC

ECC
ECC
ECC ECC ECC
ECC

NE A NEB NE C NED

S/OMS (Example Star Topology)

HÌNH 6-7
Hỗ trợ mạng con quản lý trên các cấu trúc liên kết khác nhau

6.1.2 Độ tin cậy của MCN


MCN phải được thiết kế để ngăn chặn một lỗi duy nhất làm cho việc chuyển các thông báo quản lý
quan trọng không thể thực hiện được.
MCN phải được thiết kế để đảm bảo rằng sự tắc nghẽn trong MCN không gây ra việc chặn hoặc
làm chậm trễ quá mức các thông báo quản lý mạng nhằm mục đích sửa lỗi hoặc lỗi.
Các hệ điều hành và NE cung cấp chức năng khẩn cấp có thể yêu cầu các kênh truy cập thay thế
hoặc trùng lặp vào MCN để dự phòng.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
17

6.1.3 Bảo mật của MCN


Xem M.3016 để biết các yêu cầu bảo mật MCN.
6.1.4 Chức năng truyền thông dữ liệu của MCN
DCF trong các thực thể TMN sẽ hỗ trợ chức năng Hệ thống cuối (ES) (theo điều kiện OSI) hoặc
Máy chủ (theo điều kiện IP).
 Khi DCF trong các thực thể TMN hỗ trợ giao diện ECC, các chức năng sau được yêu
cầu hỗ trợ:
 Chức năng truy cập ECC (như quy định trong Phần 7.1.1)
 Chức năng kết thúc liên kết dữ liệu ECC (như quy định trong Phần 7.1.2)
 [PDU lớp mạng thành lớp liên kết dữ liệu ECC] Chức năng đóng gói (như được
chỉ định trong Phần 7.1.3)
 Khi DCF bên trong các thực thể TMN hỗ trợ giao diện Ethernet LAN, các chức năng sau
được yêu cầu để được hỗ trợ:
 Chức năng kết thúc lớp vật lý Ethernet LAN (như được nêu trong Phần 7.1.4)
 [PDU lớp mạng vào khung Ethernet] Chức năng đóng gói (như được chỉ định
trong Phần 7.1.5)
DCF trong các thực thể TMN có thể hoạt động như một Hệ thống trung gian (IS) (theo điều kiện
OSI) hoặc như một Bộ định tuyến (theo điều kiện IP). DCF bên trong các thực thể TMN hoạt động
như IS / Bộ định tuyến phải có khả năng định tuyến trong khu vực Cấp 1 của chúng và do đó phải
cung cấp chức năng của IS / Bộ định tuyến Cấp 1. Ngoài ra, DCF trong một thực thể TMN có thể
được cung cấp như một IS / Bộ định tuyến Cấp 2, cung cấp khả năng định tuyến từ khu vực này
sang khu vực khác. Chức năng của IS / Bộ định tuyến Cấp 2 không cần thiết trong DCF của tất cả
các thực thể TMN. Ví dụ về DCF hỗ trợ chức năng Bộ định tuyến / IS mức 2 có thể là DCF trong
NE cổng vào.
 Khi DCF bên trong các thực thể TMN hoạt động như một IS / Bộ định tuyến, các chức
năng sau được yêu cầu hỗ trợ:
 Chức năng chuyển tiếp PDU lớp mạng (như được nêu trong Phần 7.1.6)
 Chức năng định tuyến lớp mạng (như quy định trong Phần 7.1.10)
DCF trong thực thể TMN hỗ trợ IP có thể được kết nối trực tiếp với DCF trong thực thể TMN lân
cận chỉ hỗ trợ OSI.
 Khi DCF trong thực thể TMN hỗ trợ IP được kết nối trực tiếp với DCF trong thực thể
TMN lân cận chỉ hỗ trợ OSI, thì chức năng sau là bắt buộc phải được hỗ trợ trong IP hỗ
trợ DCF:
 Chức năng liên kết PDU của lớp mạng (như được nêu trong Phần 7.1.7)
DCF trong thực thể TMN có thể phải chuyển tiếp PDU Lớp Mạng qua mạng không hỗ trợ cùng loại
Lớp Mạng.
 Khi DCF bên trong một thực thể TMN phải chuyển tiếp PDU Lớp Mạng qua mạng
không hỗ trợ cùng loại Lớp Mạng, các chức năng sau đây là bắt buộc phải được hỗ trợ:
 Chức năng đóng gói PDU của lớp mạng (như được chỉ định trong Phần 7.1.8)
 Chức năng đường hầm PDU của lớp mạng (như quy định trong Phần 7.1.9)

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
18

DCF trong thực thể TMN hỗ trợ IP sử dụng định tuyến OSPF có thể được kết nối trực tiếp với DCF
trong thực thể TMN lân cận hỗ trợ IP sử dụng IntISIS.
 Khi DCF trong thực thể TMN hỗ trợ IP sử dụng định tuyến OSPF được kết nối trực tiếp
với DCF trong thực thể TMN lân cận hỗ trợ IP bằng IntISIS, thì chức năng sau là bắt
buộc phải được hỗ trợ trong DCF hỗ trợ OSPF:
 Chức năng kết nối định tuyến IP (như được nêu trong Mục 7.1.11)

Ứng dụng 6.2ASTN


ASTN yêu cầu một mạng truyền thông, được gọi là Mạng Truyền thông Báo hiệu (SCN) để vận
chuyển các bản tin báo hiệu giữa các thành phần ASTN (ví dụ: các thành phần CC).
Hình 6-8 minh họa mối quan hệ ví dụ của SCN và ASTN. Các giao diện giữa các phần tử khác nhau
và SCN như được minh họa trong Hình 6-8 là logic và có thể được hỗ trợ trên một giao diện SCN
vật lý duy nhất hoặc nhiều giao diện SCN.
Hình 6-9 minh họa một ví dụ về việc triển khai vật lý của một SCN hỗ trợ truyền thông báo hiệu
phân tán. Tùy thuộc vào sự lựa chọn triển khai SCN, các phần tử vật lý có thể hỗ trợ bất kỳ sự kết
hợp nào của giao diện ECC, giao diện LAN và giao diện WAN. Hình 6-9 cũng minh họa các loại
khối chức năng của mặt phẳng điều khiển có thể được hỗ trợ trong các phần tử vật lý khác nhau.
Tham khảo Khuyến nghị G.8070 và G.8080 để biết thông số kỹ thuật chi tiết liên quan đến các khối
chức năng điều khiển này. Chức năng Truyền thông Dữ liệu (DCF) là một phần của mỗi phần tử vật
lý và cung cấp chức năng truyền thông dữ liệu.

ASTN ASTN
Domain A Domain B

UNI/
E-NNI
Signaling Signaling
Communication Communication
Network Network
UNI/ UNI/ UNI/ UNI/
I-NNI/ UNI/ I-NNI/ I-NNI/ UNI/ UNI/ I-NNI/
UNI/ E-NNI
E-NNI I-NNI/ E-NNI I-NNI/ I-NNI/ E-NNI
I-NNI/
E-NNI E-NNI E-NNI
E-NNI

Network Network Network Network Network Network Network Network


Element Element Element Element Element Element Element Element

HÌNH 6-8
Mối quan hệ mẫu của Giao diện ASTN với SCN

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
19

WAN

WAN Interface

NE

CC WAN Interface
CC CC
ECC
LAN
NE NE
NE

CC NE
LAN
CC

CC ECC CC
ECC
ECC
NE NE
CC CC

NE NE

Data Communication
Function (DCF)

Physical Element
Function Block

HÌNH 6-9
Ví dụ về việc thực hiện vật lý của SCN hỗ trợ ASTN

6.2.1 Cơ cấu học của SCN


Hình 6-10 minh họa các cấu trúc liên kết ví dụ như tuyến tính, vòng, lưới và hình sao sử dụng ECC
và / hoặc Mạng truyền thông cục bộ (LCN) (ví dụ: Ethernet LAN) làm các liên kết vật lý kết nối các
Phần tử mạng. Hình 6-11 minh họa cách một Mạng Báo hiệu ASTN có thể được hỗ trợ trên mỗi cấu
trúc liên kết. Điểm chung cho mỗi cấu trúc liên kết là tồn tại các đường dẫn đa dạng khác nhau giữa
các thực thể giao tiếp (tức là các NE có khả năng ASTN). Lưu ý rằng để hỗ trợ các đường dẫn đa
dạng thay thế giữa các ASTN NE giao tiếp theo cấu trúc liên kết tuyến tính, một liên kết WAN bên
ngoài có thể được cung cấp giữa các cạnh ASTN NE.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
20

LCN

NE1 NEA NEB NE C NE D NE2


ECC ECC ECC ECC

(Example Linear Topology)

ECC ECC ECC


NE1 NEB NEC NE2 NE1 NE2

ECC ECC
ECC ECC ECC ECC
LCN

NEA NED NEA NEB NEC NED

ECC
ECC ECC
ECC ECC
ECC ECC

NEE NEF NEG NEE NEF NEG


ECC ECC ECC ECC

(Example Ring Topology) (Example Mesh Topology)

NE1 NE2
ECC ECC

ECC
ECC
ECC ECC ECC
ECC

NEA NEB NEC NED

(Example Star Topology)

HÌNH 6-10
Cấu trúc liên kết mẫu

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
21

WAN

LCN

ASTN ASTN ASTN ASTN ASTN ASTN


NE1 NEA ECC NE B NE C ECC NE D ECC NE2
ECC

ASTN Signalling Network (Example Linear Topology)

ECC ECC ECC


ASTN ASTN ASTN ASTN ASTN ASTN
NE1 NEB NEC NE2 NE1 NE2

ECC ECC
ECC ECC ECC ECC
LCN

ASTN ASTN ASTN ASTN ASTN ASTN


NEA NED NEA NE B NEC NED

ECC
ECC ECC
ECC ECC
ECC ECC
ASTN ASTN ASTN ASTN ASTN ASTN
NEE NE F NEG NE E NEF NEG
ECC ECC ECC ECC

ASTN Signalling Network (Example Ring Topology) ASTN Signalling Network (Example Mesh Topology)

ASTN ASTN
NE1 NE2
ECC ECC

ECC
ECC
ECC ECC ECC
ECC

ASTN ASTN ASTN ASTN


NEA NE B NEC NED

ASTN Signalling Network (Example Star Topology)

HÌNH 6-11
Hỗ trợ mạng báo hiệu ASTN trên các cấu trúc liên kết khác nhau

Hình 6-12 minh họa cách Mạng báo hiệu ASTN có thể bao gồm ba phần khác nhau; phần mạng
khách hàng, phần miền quản trị nội bộ và phần miền liên quản trị. Ví dụ này cho thấy cấu trúc liên
kết lưới sử dụng ECC, Mạng truyền thông cục bộ (ví dụ: Ethernet LAN) và Đường cho thuê (ví dụ:
DS1 / E1, VC-3/4) làm các liên kết vật lý kết nối các NE của ASTN. Cấu trúc liên kết của phần
miền nội bộ quản trị cho phép báo hiệu I-NNI có các đường dẫn đa dạng thay thế giữa hai ASTN
NE giao tiếp. Cấu trúc liên kết của phần miền liên quản trị phụ thuộc vào các thỏa thuận giữa các
Miền quản trị A và B. Ví dụ này minh họa các điểm truy cập kép giữa các Miền quản trị. Cấu trúc
liên kết của Khách hàng - Phần mạng phụ thuộc vào các thỏa thuận giữa khách hàng và nhà cung
cấp dịch vụ. Ví dụ này minh họa một điểm truy cập duy nhất giữa khách hàng và mạng.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
22

Customer-Network Intra-Administrative Inter-Administrative


Portion Domain Portion Domain Portion
of Signaling Network of Signaling Network of Signaling Network

ASTN ECC
ECC Leased Line ASTN
NE
NE
AST N
ECC or LCN
AST N AST N NE
NE NE
Leased Line
LCN

LCN
ECC AST N
ASTN
NE
ASTN ECC NE
NE

Customer Administrative Administrative


Domain A Domain B

HÌNH 6-12
Ví dụ về SCN

6.2.2 Độ tin cậy của SCN

Hình 6-13 minh họa các bản tin điều khiển ASTN được truyền qua SCN. Hình minh họa các giao
diện logic sau:
UNI - Người dùng - Giao diện mạng.
NNI - Mạng - Giao diện mạng.
CCI - Giao diện bộ điều khiển kết nối.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
23

UNI UNI
CallC CallC CallC CallC

NNI NNI NNI NNI

NNI
CC CC CC CC

CCI CCI CCI CCI CCI

Client Server Server Server Client

HÌNH 6-13
Giao diện ASTN được hỗ trợ trên SCN

Trong ví dụ này, các giao diện logic UNI, NNI và CCI được truyền qua mạng SCN. SCN có thể bao
gồm các mạng con khác nhau, trong đó các liên kết logic trong một số mạng con có thể chia sẻ các
tuyến vật lý chung với mạng truyền tải nhưng điều đó không bắt buộc hoặc bị loại trừ.
SCN có thể gặp lỗi độc lập với mạng truyền tải. Một kịch bản như vậy được minh họa trong Hình 6-
14 và Hình 6-15. Trong ví dụ này, tập trung vào các thông báo ASTN được truyền qua SCN, một
lỗi độc lập đối với SCN sẽ ảnh hưởng đến thiết lập kết nối mới và các yêu cầu gỡ bỏ kết nối.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
24

UNI UNI
CallC CallC CallC CallC

NNI NNI NNI NNI

NNI
CC CC CC CC

CCI CCI CCI CCI CCI

Client Server Server Server Client

HÌNH 6-14
Lỗi SCN ảnh hưởng đến giao diện tín hiệu

UNI UNI
CallC CallC CallC CallC

NNI NNI NNI NNI

NNI
CC CC CC CC

CCI CCI CCI CCI CCI

Client Server Server Server Client

HÌNH 6-15
Lỗi SCN ảnh hưởng đến giao diện CCI

Như đã chỉ ra ở trên, một số liên kết logic trong SCN cũng có thể chia sẻ các tuyến đường vật lý
chung với mạng lưới giao thông. Trong trường hợp này, SCN có thể gặp sự cố không độc lập với
mạng truyền tải (nghĩa là, sự cố làm gián đoạn cả lưu lượng SCN cũng như lưu lượng vận chuyển),

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
25

như thể hiện trong Hình 6-16. Trong ví dụ này, tập trung vào các thông báo ASTN được vận chuyển
qua SCN, lỗi như vậy có thể ảnh hưởng đến việc khôi phục khi ASTN được sử dụng để khôi phục
các kết nối hiện có. Do đó, điều quan trọng đối với SCN là cung cấp khả năng phục hồi khi vận
chuyển các thông báo khôi phục.

UNI UNI
CallC CallC CallC CallC

NNI NNI NNI NNI

NNI
CC CC CC CC

CCI CCI CCI CCI CCI

Client Server Server Server Client

HÌNH 6-16
Lỗi SCN ảnh hưởng đến cả giao diện tín hiệu và dữ liệu

Nếu ứng dụng ASTN chỉ được sử dụng để cung cấp thiết lập và chia nhỏ kết nối, thì một SCN
không kết nối có thể là đủ. Tuy nhiên, nếu ứng dụng ASTN cũng được sử dụng để khôi phục, thì có
thể yêu cầu SCN hướng kết nối. Một SCN hướng kết nối sẽ yêu cầu đặc tả các chức năng bổ sung
để hỗ trợ các dịch vụ mạng hướng kết nối.
Các yêu cầu về độ tin cậy của SCN như sau:
SCN sẽ hỗ trợ các mức khôi phục khác nhau tùy thuộc vào các yêu cầu về độ tin cậy của các thành
phần giao tiếp mà nó cung cấp vận chuyển (nghĩa là, việc khôi phục có thể được hỗ trợ giữa các
thành phần giao tiếp yêu cầu thông tin liên lạc có độ tin cậy cao mà không yêu cầu khôi phục được
hỗ trợ giữa tất cả các thành phần giao tiếp).
SCN có thể cung cấp sự vận chuyển cho các thông báo khôi phục. Trong trường hợp như vậy, SCN
phải cung cấp tốc độ khôi phục, cho phép vận hành thích hợp các kết nối mà thông báo khôi phục
điều khiển.
6.2.3 Bảo mật của SCN
Một SCN hỗ trợ các bản tin ASTN có thể cung cấp kết nối giữa các miền quản trị khác nhau để hỗ
trợ việc truyền tải các bản tin UNI hoặc E-NNI (tức là các bản tin vượt qua ranh giới hành chính).
Thông báo I-NNI chỉ được phép trong một miền quản trị duy nhất. Khi một SCN cung cấp kết nối
giữa các ranh giới hành chính, phải có các biện pháp phòng ngừa sao cho chỉ những thông báo (ví
dụ: thông điệp E-NNI) được phép chuyển giữa hai miền quản trị mới có thể vượt qua giao diện
trong khi các thông báo khác không được phép giữa các miền quản trị (ví dụ: thông báo I-NNI) bị
ngăn không cho vượt qua giao diện. Hình 6-17 minh họa một ví dụ trong đó một SCN hỗ trợ truyền
thông điệp ASTN được kết nối với nhau với nhiều miền quản trị.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
26

Interface Connecting DCNs, Interface Connecting DCNs,


supporting the Control Plane, supporting the Control Plane,
of Different Domains of Different Domains

Adminstrative
Domain B

Route Not
Allowed

Allowed Route

Adminstrative
Domain A

I-NNI Messages

E-NNI Messages

UNI Messages

HÌNH 6-17
Các khía cạnh bảo mật của SCN

6.2.4 Các chức năng truyền thông dữ liệu của SCN


DCF trong các thực thể ASTN sẽ hỗ trợ chức năng Hệ thống cuối (ES) (theo điều kiện OSI) hoặc
Máy chủ (theo điều kiện IP).
 Khi DCF trong các thực thể ASTN hỗ trợ giao diện ECC, các chức năng sau được yêu
cầu để được hỗ trợ:
 Chức năng truy cập ECC (như quy định trong Phần 7.1.1)
 Chức năng kết thúc liên kết dữ liệu ECC (như quy định trong Phần 7.1.2)
 [PDU lớp mạng thành lớp liên kết dữ liệu ECC] Chức năng đóng gói (như được
chỉ định trong Phần 7.1.3)
 Khi DCF trong các thực thể ASTN hỗ trợ giao diện Ethernet LAN, các chức năng sau
được yêu cầu để được hỗ trợ:
 Chức năng kết thúc lớp vật lý Ethernet LAN (như được nêu trong Phần 7.1.4)
 [PDU lớp mạng vào khung Ethernet] Chức năng đóng gói (như được chỉ định
trong Phần 7.1.5)

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
27

DCF trong các thực thể ASTN có thể hoạt động như một Hệ thống trung gian (IS) (theo điều kiện
OSI) hoặc như một Bộ định tuyến (theo điều kiện IP). DCF trong các thực thể ASTN hoạt động như
IS / Bộ định tuyến phải có khả năng định tuyến trong khu vực Cấp 1 của chúng và do đó phải cung
cấp chức năng của IS / Bộ định tuyến Cấp 1. Ngoài ra, DCF trong một thực thể ASTN có thể được
cung cấp dưới dạng IS / Bộ định tuyến Cấp 2, cung cấp khả năng định tuyến từ khu vực này sang
khu vực khác. Chức năng của IS / Bộ định tuyến Cấp 2 không cần thiết trong DCF của tất cả các
thực thể ASTN.
 Khi DCF trong các thực thể ASTN hoạt động như một IS / Bộ định tuyến, các chức năng
sau là bắt buộc phải được hỗ trợ:
 Chức năng chuyển tiếp PDU lớp mạng (như được nêu trong Phần 7.1.6)
 Chức năng định tuyến lớp mạng (như quy định trong Phần 7.1.10)
DCF trong thực thể ASTN hỗ trợ IP có thể được kết nối trực tiếp với DCF trong thực thể ASTN lân
cận chỉ hỗ trợ OSI.
 Khi DCF trong thực thể ASTN hỗ trợ IP được kết nối trực tiếp với DCF trong thực thể
TMN lân cận chỉ hỗ trợ OSI, thì chức năng sau là bắt buộc phải được hỗ trợ trong IP hỗ
trợ DCF:
 Chức năng liên kết PDU của lớp mạng (như được nêu trong Phần 7.1.7)
DCF trong thực thể ASTN có thể phải chuyển tiếp PDU Lớp Mạng qua mạng không hỗ trợ cùng
loại Lớp Mạng.
 Khi DCF trong một thực thể ASTN phải chuyển tiếp PDU Lớp Mạng qua mạng không
hỗ trợ cùng loại Lớp Mạng, các chức năng sau đây là bắt buộc phải được hỗ trợ:
 Chức năng đóng gói PDU của lớp mạng (như được chỉ định trong Phần 7.1.8)
 Chức năng đường hầm PDU của lớp mạng (như quy định trong Phần 7.1.9)
DCF trong thực thể ASTN hỗ trợ IP sử dụng định tuyến OSPF có thể được kết nối trực tiếp với
DCF trong thực thể ASTN lân cận hỗ trợ IP sử dụng IntISIS.
 Khi DCF trong thực thể ASTN hỗ trợ IP sử dụng định tuyến OSPF được kết nối trực tiếp
với DCF trong thực thể ASTN lân cận hỗ trợ IP sử dụng IntISIS, thì chức năng sau là bắt
buộc phải được hỗ trợ trong DCF hỗ trợ OSPF:
 Chức năng kết nối định tuyến IP (như được nêu trong Mục 7.1.11)

6.3 Các ứng dụng khác Yêu cầu Mạng Truyền thông
Bên cạnh các ứng dụng TMN và ASTN, các ứng dụng khác như thông tin liên lạc bằng giọng nói
(ví dụ: orderwire), tải xuống phần mềm, thông tin liên lạc cụ thể của nhà điều hành, yêu cầu một
mạng truyền thông để cung cấp việc vận chuyển thông tin giữa các thành phần.

6.4 Tách các ứng dụng khác nhau


Tùy thuộc vào thiết kế mạng, kích thước mạng, dung lượng liên kết, yêu cầu bảo mật và yêu cầu
hiệu suất, có thể có nhiều mức phân tách khác nhau giữa nhiều ứng dụng (ví dụ: TMN, ASTN).
Mức độ tách biệt được cung cấp là sự lựa chọn giữa các nhà khai thác và nhà cung cấp khi thiết kế
mạng. Sau đây là các ví dụ về các mức độ phân tách khác nhau.
Tùy chọn A: DCN có thể được thiết kế sao cho MCN, SCN và các ứng dụng khác (ví dụ: liên lạc cụ
thể của nhà điều hành) được hỗ trợ trên cùng một mạng lớp 3 (ví dụ: chia sẻ cùng một mạng IP).

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
28

Tùy chọn B: DCN có thể được thiết kế sao cho MCN, SCN và các ứng dụng khác (ví dụ: truyền
thông cụ thể của nhà điều hành) được hỗ trợ trên các mạng lớp 3 riêng biệt, tuy nhiên chúng có thể
chia sẻ một số liên kết vật lý giống nhau.
Tùy chọn C: DCN có thể được thiết kế sao cho MCN, SCN và các ứng dụng khác (ví dụ: liên lạc cụ
thể của nhà điều hành) được hỗ trợ trên các mạng vật lý riêng biệt (tức là các mạng lớp 3 riêng biệt
không chia sẻ bất kỳ liên kết vật lý nào giống nhau).

Kiến trúc và yêu cầu chức năng 7DCN


Yêu cầu về kiến trúc DCN trong phần này áp dụng cho Miền chỉ IP, Miền chỉ OSI và miền IP +
OSI hỗn hợp. Các yêu cầu về kiến trúc DCN là độc lập về công nghệ. Các khuyến nghị cụ thể về
công nghệ như Khuyến nghị G.784 cho SDH và Khuyến nghị G.874 cho OTN sẽ chỉ rõ những yêu
cầu nào có thể áp dụng cho công nghệ cụ thể đó.
DCN nhận thức được các giao thức Lớp 1, Lớp 2 và Lớp 3 và minh bạch với các giao thức lớp trên
được sử dụng bởi các ứng dụng mà nó vận chuyển.
DCN có thể được thiết kế sao cho chỉ IP được hỗ trợ. Một DCN chỉ hỗ trợ IP có thể bao gồm nhiều
mạng con khác nhau sử dụng các giao thức lớp liên kết vật lý và dữ liệu khác nhau, tuy nhiên, tất cả
các mạng con sẽ hỗ trợ IP làm giao thức lớp mạng.
Tuy nhiên, vì mạng DCN nhúng hỗ trợ OSI, một số DCN có thể bao gồm các bộ phận chỉ hỗ trợ IP,
các bộ phận chỉ hỗ trợ OSI và các bộ phận hỗ trợ cả IP và OSI.
Những phần của DCN hỗ trợ IP (tức là những phần chỉ hỗ trợ IP hoặc những phần hỗ trợ IP và OSI)
có thể bao gồm các DCF hỗ trợ chỉ IP (tức là một ngăn xếp DCF chỉ IP) và / hoặc các DCF hỗ trợ
IP và OSI (ví dụ: DCF ngăn xếp kép có khả năng định tuyến cả gói IP và OSI). Những phần của
DCN chỉ hỗ trợ OSI, sẽ bao gồm các DCF chỉ hỗ trợ OSI (tức là DCF chỉ dành cho OSI một ngăn
xếp).
Hình 7-1 minh họa kiến trúc chức năng của DCN. Như đã thảo luận ở trên, DCN có thể bao gồm
các bộ phận chỉ hỗ trợ IP, các bộ phận chỉ hỗ trợ OSI và các bộ phận hỗ trợ cả IP và OSI. Chức
năng liên làm việc (IWF) giữa các phần của DCN chỉ hỗ trợ IP, chỉ OSI và IP và OSI, đồng thời các
chức năng ánh xạ ánh xạ các ứng dụng tới lớp IP cũng được chỉ định. Để cung cấp khả năng vận
chuyển như vậy, DCN hỗ trợ chức năng Lớp 1 (vật lý), Lớp 2 (liên kết dữ liệu) và Lớp 3 (mạng).
Các yêu cầu về kiến trúc đối với các phần của DCN chỉ hỗ trợ IP, chỉ OSI cũng như các yêu cầu về
khả năng làm việc lẫn nhau giữa các phần đó của DCN chỉ hỗ trợ IP, chỉ OSI và IP và OSI) được
chỉ định. Đám mây trong Hình 7-1, đại diện cho phần IP duy nhất của DCN,

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
29

OS OS OS OS
Applications

m m m m

IP-only OSI-only
DCN Layer 1, 2, 3 IWF Layer 1, 2, 3
Functionality Functionality

m m m m m m
Applications
SNCr EMF SNCr EMF EMF SNCr

IWF - Interworking Function


SNCr - Subnetwork Connection Controller
EMF - Equipment Management Function
OS - Operations System
m - mapping between Application and DCN

HÌNH 7-1
Kiến trúc chức năng của DCN

7.1 Đặc điểm kỹ thuật của các chức năng truyền thông dữ liệu
Phần này cung cấp thông số kỹ thuật cho các chức năng giao tiếp dữ liệu khác nhau liên quan đến
giao diện ECC, giao diện Ethernet LAN và các khả năng của lớp mạng.
7.1.1 Chức năng truy cậpECC
Chức năng truy cập ECC cung cấp quyền truy cập vào dòng bit ECC. Chức năng này được xác định
trong các khuyến nghị thiết bị cụ thể về công nghệ (ví dụ: G.783, G.798). Tốc độ bit và định nghĩa
của các ECC khác nhau (ví dụ: DCC, GCC và COMMS OH trong OSC) được cung cấp trong các
khuyến nghị cụ thể về công nghệ (ví dụ: G.784, G.874).
7.1.2 Chức năng kết thúc lớp liên kết dữ liệu củaECC
Chức năng kết thúc lớp liên kết dữ liệu ECC cung cấp xử lý lớp liên kết dữ liệu chung bất kể PDU
lớp mạng được đóng gói trong Khung lớp liên kết dữ liệu. Chức năng này cũng cung cấp ánh xạ của
Khung lớp liên kết dữ liệu vào ECC. Chức năng này được chỉ định trong các khuyến nghị cụ thể về
công nghệ. Tuy nhiên, thông số kỹ thuật cho Chức năng kết thúc lớp liên kết dữ liệu SDH ECC
được cung cấp bên dưới.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
30

7.1.2.1 Chức năng kết thúc lớp liên kết dữ liệu SDH ECC
7.1.2.1.1 Ánh xạ Khung lớp liên kết dữ liệu SDH vào ECC
Tín hiệu khung HDLC là một dòng bit nối tiếp chứa các khung nhồi được bao quanh bởi một hoặc
nhiều chuỗi cờ. Định dạng tín hiệu khung HDLC được xác định trong Khuyến nghị ITU-T Q.921
cho LAPD và RFC 1662 cho PPP trong khung HDLC. Khung HDLC bao gồm N octet như được
trình bày trong Hình 7-2. Khung HDLC được truyền từ phải sang trái và từ trên xuống dưới. Một bit
0 được chèn vào sau tất cả các chuỗi gồm năm bit 1 liên tiếp trong nội dung khung HDLC (octet 2
đến N-1) đảm bảo rằng cờ hoặc trình tự hủy bỏ không được mô phỏng trong khung.
Ánh xạ của tín hiệu được đóng khung HDLC vào kênh DCC là đồng bộ bit (chứ không phải là đồng
bộ octet) vì khung HDLC nhồi không nhất thiết phải chứa một số nguyên các octet do quá trình
chèn 0. Do đó, không có ánh xạ trực tiếp của khung HDLC nhồi vào các byte trong kênh DCC. Bộ
tạo tín hiệu HDLC lấy thời gian của nó từ hàm ServerLayer / DCC_A (tức là tín hiệu DCC_CI_CK)
cho SDH. Các chức năng ServerLayer / DCC_A sau được định nghĩa trong Khuyến nghị G.783;
Hàm MSn / DCC_A, hàm MS256 / DCC_A và hàm RSn / DCC_A.
Tín hiệu khung HDLC là một dòng bit nối tiếp và sẽ được chèn vào kênh DCC sao cho các bit sẽ
được truyền trên STM-N theo thứ tự mà chúng đã được nhận từ bộ tạo tín hiệu khung HDLC.

8 7 6 5 4 3 2 1
Flag
0 1 1 1 1 1 1 0 Octet 1

N-2

N-1

Flag
N
0 1 1 1 1 1 1 0

HÌNH 7-2
Định dạng khung HDLC

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
31

7.1.2.1.2 Đặc điểm kỹ thuật giao thức lớp liên kết dữ liệu ECC của SDH
Ba loại giao diện được xác định là; Giao diện chỉ IP, giao diện chỉ OSI và Giao diện kép (Giao diện
kép là giao diện có thể mang cả gói IP và OSI). Khi chỉ mang IP qua DCC, khung PPPinHDLC sẽ
được sử dụng làm giao thức lớp liên kết dữ liệu. Vì Giao diện kép có thể mang cả IP và OSI, nên
Giao diện kép có thể được kết nối với giao diện chỉ IP, giao diện chỉ dành cho OSI hoặc giao diện
Kép khác. Các giao diện chỉ dành cho OSI tồn tại trong các mạng ngày nay và giao thức liên kết dữ
liệu được sử dụng trên các giao diện đó là LAPD như được định nghĩa trong Khuyến nghị G.784.
Để cho phép Giao diện kép kết nối với giao diện chỉ IP hoặc giao diện chỉ OSI, giao thức lớp liên
kết dữ liệu được hỗ trợ trên Giao diện kép phải có thể định cấu hình để hỗ trợ PPPinHDLC hoặc
LAPD. Một ngoại lệ được cho phép đối với các NE SDH được nhúng hỗ trợ LAPD trong phần
cứng được nâng cấp để hỗ trợ Giao diện kép. Để giới hạn số lượng nâng cấp phần cứng, cho phép
các NE SDH đã nâng cấp chỉ hỗ trợ LAPD.
7.1.2.1.2.1 Giao diện chỉ IP
Giao diện chỉ IP được minh họa trong Hình 7-3.
I P- only
in ter fa ce
IP
PP P
DC C

HÌNH 7-3
Giao diện chỉ IP

Giao diện chỉ IP sẽ sử dụng PPP theo RFC 1661.


7.1.2.1.2.2 Giao diện chỉ dành cho hệ điều hànhOSI
Các giao diện chỉ dành cho OSI được minh họa trong Hình 7-4.
OS I- only
I nte r fa ce
OSI
LAP D
DCC

HÌNH 7-4
Giao diện chỉ dành cho OSI

Các giao diện chỉ dành cho OSI sẽ sử dụng LAPD theo Khuyến nghị G.784.
7.1.2.1.2.3 Giao diện kép (IP + OSI)
Giao diện kép (Giao diện kép là giao diện có thể mang gói OSI và IP) có thể được kết nối với giao
diện chỉ IP, giao diện chỉ OSI hoặc các giao diện Kép khác. Để cho phép các giao diện Kép được
kết nối với các giao diện chỉ IP khác hoặc các giao diện chỉ OSI khác, giao thức liên kết dữ liệu trên
giao diện Kép phải được định cấu hình để chuyển đổi giữa PPP trong khung HDLC (theo RFC

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
32

1662) và LAPD (theo G.784) như minh họa trong Hình 7-5. Lưu ý rằng các NE SDH được nhúng
hỗ trợ LAPD trong phần cứng được nâng cấp để hỗ trợ IP không bắt buộc phải hỗ trợ PPP trong
khung HDLC trên giao diện kép của nó. Do đó, các giao diện kép của nó chỉ được yêu cầu để hỗ trợ
LAPD.
Du al-St ack Int erface D ual -Stack In terface

IP+OSI IP+O SI
i n terface i nt erface
IP +OSI IP+O SI
PPP L APD
DCC D CC

HÌNH 7-5
Giao diện kép

Các giao diện kép hỗ trợ PPP sẽ sử dụng PPP theo RFC 1661.
Các giao diện kép hỗ trợ LAPD sẽ sử dụng LAPD theo Khuyến nghị G.784.
7.1.3 [PDU lớp mạng vào khung liên kết dữ liệu ECC] Chức năng đóng gói
Chức năng đóng gói [PDU lớp mạng vào khung liên kết dữ liệu ECC] đóng gói và bỏ đóng gói
PDU lớp mạng vào khung liên kết dữ liệu. Hàm này cũng xử lý mã định danh giao thức. Chức năng
này được xác định trong các khuyến nghị cụ thể về công nghệ. Tuy nhiên, đặc điểm kỹ thuật cho
Chức năng đóng gói [PDU lớp mạng vào khung liên kết dữ liệu SDH ECC] được cung cấp bên
dưới.
7.1.3.1 [PDU lớp mạng vào khung liên kết dữ liệu SDH ECC] Chức năng đóng gói
Đặc điểm kỹ thuật của Chức năng đóng gói [PDU lớp mạng vào khung liên kết dữ liệu ECC SDH]
cho giao diện chỉ IP, giao diện chỉ OSI và Giao diện kép được cung cấp bên dưới.
7.1.3.1.1 Giao diện chỉ IP
Giao diện chỉ IP phải chỉ sử dụng IP / PPPinHDLCframing / DCC theo RFC 1662.
Giao diện chỉ IP được định nghĩa như sau:
Kết thúc truyền:
– Sẽ đặt các gói IPv4 trực tiếp vào Trường thông tin PPP theo RFC 1661 với giá trị giao thức
IPv4 theo RFC 1332 vào Trường giao thức PPP.
– Sẽ đặt các gói IPv6 trực tiếp vào Trường thông tin PPP theo RFC 1661 với giá trị giao thức
IPv6 theo RFC 2472 vào Trường giao thức PPP.
Kết thúc Nhận:
– Gói IPv4 được xác định nếu Trường giao thức PPP có giá trị giao thức IPv4 theo RFC 1332.
– Gói IPv6 được xác định nếu Trường giao thức PPP có giá trị giao thức IPv6 theo RFC 2472.
7.1.3.1.2 Giao diện chỉ dành cho hệ điều hànhOSI
Các giao diện chỉ dành cho OSI chỉ được sử dụng OSI / LAPD / DCC theo Khuyến nghị G.784.
Giao diện chỉ dành cho OSI được định nghĩa như sau:

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
33

Kết thúc truyền:


– Sẽ đặt các gói OSI trực tiếp vào tải trọng LAPD theo Khuyến nghị G.784
Kết thúc Nhận:
– Sẽ kiểm tra mã định danh giao thức nằm trong octet đầu tiên của tải trọng LAPD. Giá trị của số
nhận dạng này phù hợp với các giá trị được chỉ định trong ISO 9577 / ITU-T X.263. Nếu PDU
nhận được dành cho một giao thức không được máy thu hỗ trợ, thì PDU đó sẽ bị loại bỏ.
7.1.3.1.3 Giao diện kép (IP + OSI)
Giao diện kép hỗ trợ PPP làm giao thức liên kết dữ liệu được định nghĩa như sau:
Kết thúc truyền:
– Sẽ đặt các gói OSI trực tiếp vào Trường Thông tin PPP theo RFC 1661 với giá trị giao thức OSI
theo RFC 1377 vào Trường Giao thức PPP.
– Sẽ đặt các gói IPv4 trực tiếp vào Trường thông tin PPP theo RFC 1661 với giá trị giao thức
IPv4 theo RFC 1332 vào Trường giao thức PPP.
– Sẽ đặt các gói IPv6 trực tiếp vào Trường thông tin PPP theo RFC 1661 với giá trị giao thức
IPv6 theo RFC 2472 vào Trường giao thức PPP.
Kết thúc Nhận:
– Gói OSI được xác định nếu Trường giao thức PPP có giá trị giao thức OSI theo RFC 1377.
– Gói IPv4 được xác định nếu Trường giao thức PPP có giá trị giao thức IPv4 theo RFC 1332.
– Gói IPv6 được xác định nếu Trường giao thức PPP có giá trị giao thức IPv6 theo RFC 2472.
Giao diện kép hỗ trợ LAPD làm giao thức liên kết dữ liệu được định nghĩa như sau:
Kết thúc truyền:
– Sẽ đặt các gói OSI trực tiếp vào tải trọng LAPD theo G.784.
– Sẽ đặt các gói IP trực tiếp vào tải trọng LAPD, với một mã định danh giao thức một octet được
thêm vào trước. Giá trị nhận dạng này sẽ nhất quán với các giá trị được gán ISO 9577 / ITU-T
X.263 cho IPv4 và IPv6.
Kết thúc Nhận:
– Sẽ kiểm tra mã định danh giao thức nằm trong octet đầu tiên của tải trọng LAPD. Giá trị của số
nhận dạng này phù hợp với các giá trị được chỉ định trong ISO 9577 / ITU-T X.263. Nếu PDU
nhận được dành cho một giao thức không được máy thu hỗ trợ, thì PDU đó sẽ bị loại bỏ.
7.1.4 Chức năng kết thúc vật lý mạng Ethernet LAN
Chức năng kết thúc vật lý Ethernet LAN kết thúc giao diện ethernet vật lý.
Một hoặc nhiều tốc độ sau sẽ được hỗ trợ: 1 Mbps, 10 Mbps, 100 Mbps.
Quyền truy cập vào các kênh ECC đã kết thúc được cho phép bởi Phần tử mạng hỗ trợ giao diện
Ethernet LAN. Không phải tất cả các phần tử mạng hỗ trợ kênh ECC đều cần hỗ trợ cổng Ethernet
LAN, miễn là có một đường dẫn ECC từ Phần tử mạng kết thúc kênh ECC và Phần tử mạng khác
cung cấp cổng Ethernet LAN.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
34

7.1.5 [PDU lớp mạng vào khung Ethernet] Chức năng đóng gói
Chức năng này đóng gói và không đóng gói một PDU Lớp Mạng vào một khung 802.3 hoặc
Ethernet (phiên bản 2).
Nó sẽ đóng gói các PDU của lớp mạng thành các khung 802.3 hoặc Ethernet (phiên bản 2) theo các
quy tắc sau.
 Nó sẽ đóng gói và không đóng gói các PDU CLNP, ISIS và ESIS thành các khung 802.3 theo
Khuyến nghị Q.811.
 Nó sẽ đóng gói và không đóng gói các gói IP vào các khung Ethernet (phiên bản 2) theo RFC
894.
 Địa chỉ IP sẽ được ánh xạ tới địa chỉ MAC ethernet sử dụng Giao thức phân giải địa chỉ trong
RFC 826.
Nó sẽ xác định loại khung nhận được (802.3 hoặc Ethernet phiên bản 2) theo Mục 2.3.3 trong RFC
1122.
7.1.6 Chức năng chuyển tiếp PDU của lớp mạng
Chức năng chuyển tiếp PDU của lớp mạng chuyển tiếp các gói của lớp mạng.
Nếu hàm này chuyển tiếp các gói CLNP, nó sẽ chuyển tiếp các gói CLNP theo Khuyến nghị Q.811.
Nếu hàm này chuyển tiếp các gói IPv4, nó sẽ chuyển tiếp các gói IPv4 theo RFC 791.
Nếu chức năng này chuyển tiếp các gói IPv6, nó sẽ chuyển tiếp các gói IPv6 theo RFC 2460.
Định dạng địa chỉ ưa thích là IPv6. Giao thức định tuyến IP phải có thể xử lý địa chỉ IPv6 và IPv4.
7.1.7 Chức năng liên kết PDU của lớp mạng
Chức năng liên kết PDU của lớp mạng đảm bảo các chức năng DCF lân cận chạy các giao thức lớp
mạng khác nhau có thể giao tiếp. IP hỗ trợ DCF được yêu cầu để hỗ trợ OSI để cho phép giao tiếp
với DCF lân cận chỉ hỗ trợ OSI.
7.1.8 Chức năng đóng gói PDU của lớp mạng
Chức năng đóng gói PDU của lớp mạng đóng gói và không đóng gói PDU của lớp mạng này thành
PDU của lớp mạng khác.
Các gói CLNP sẽ được đóng gói qua IP bằng cách sử dụng Đóng gói định tuyến chung (GRE), như
được chỉ định trong RFC 2784, như trọng tải trong gói IP sử dụng số giao thức IP là 47 (thập phân)
và không đặt bit DF (Don't Fragment) . Theo RFC 2784, GRE sẽ chứa Ethertype để chỉ ra giao thức
lớp mạng nào đang được đóng gói. Tiêu chuẩn công nghiệp cho OSI Ethertype, là 00FE (hex) sẽ
được sử dụng.
Các gói IP phải được đóng gói qua CLNS bằng cách sử dụng GRE, như được chỉ định trong RFC
2784, là trọng tải dữ liệu của PDU kiểu dữ liệu CLNP như được chỉ định trong ISO / IEC 8473-1,
sử dụng giá trị bộ chọn NSAP là 47 (thập phân) và với SP (cho phép phân đoạn) đã đặt cờ.
Các gói IP sẽ được đóng gói qua IP bằng GRE, như được chỉ định trong RFC 2784, như trọng tải
trong gói IP sử dụng số giao thức IP là 47 (thập phân) và không đặt bit DF (Don't Fragment).
Như một tùy chọn, Chức năng đóng gói PDU lớp mạng có thể chuyển tiếp các PDU qua các nút
không tương thích thông qua quy trình đóng gói tự động được mô tả trong Phụ lục B. Lưu ý rằng
DCF hỗ trợ quy trình đóng gói tự động được mô tả trong Phụ lục B tương thích và có thể được triển
khai trong cùng khu vực với DCF không hỗ trợ quy trình đóng gói tự động thủ tục.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
35

7.1.9 Chức năng đào đường hầm lớp mạng


Chức năng Đường hầm PDU của Lớp mạng cung cấp một đường hầm tĩnh giữa hai DCF hỗ trợ
cùng một lớp mạng PDU.
Đối với một đường hầm có kích thước MTU đã định cấu hình, bất kỳ gói IP nào không thể chuyển
tiếp qua đường hầm vì nó lớn hơn kích thước MTU và có bit DF của nó, sẽ bị loại bỏ và thông báo
lỗi không thể truy cập ICMP (cụ thể là “ cần phân mảnh và mã DF set ") phải được gửi lại cho
người khởi tạo gói.
7.1.10 Chức năng định tuyến lớp mạng
Chức năng định tuyến lớp mạng định tuyến các gói dữ liệu lớp mạng.
DCF hỗ trợ định tuyến OSI sẽ hỗ trợ ISIS theo ISO 10589.
DCF hỗ trợ định tuyến IP sẽ hỗ trợ ISIS Tích hợp (xem Phần 7.1.10.1 về các yêu cầu ISIS Tích
hợp) và cũng có thể hỗ trợ OSPF cũng như các giao thức định tuyến IP khác.
7.1.10.1 Yêu cầu ISIS tích hợp
DCF hỗ trợ ISIS tích hợp sẽ hỗ trợ RFC 1195.
Một DCF hỗ trợ IS-IS tích hợp sẽ hỗ trợ Bắt tay ba chiều trên tất cả các liên kết điểm-điểm (xem
Phụ lục A về các yêu cầu Bắt tay ba chiều). Bắt tay ba chiều sửa đổi hành vi tạo và duy trì kề cận
được quy định trong ISO / IEC 10589.
7.1.10.1.1 Mức độ gần kề về nhận thức giao thức lớp mạng Sự sáng tạo
DCF sẽ bao gồm một TLV “được hỗ trợ giao thức” trong các PDU al IIH và ISH trên tất cả các giao
diện và trong tất cả các LSP có LSP số 0, theo RFC 1195.
Khi nhận được IS-IS ISH hoặc IIH PDU, DCF sẽ kiểm tra PDU để xem nó có chứa "Các giao thức
được hỗ trợ" TLV. Điều này sẽ diễn ra trên tất cả các giao diện, dù là LAN, DCC hay các liên kết
khác. Nếu ISH hoặc IIH PDU không chứaTLV “các giao thức được hỗ trợ”, thì nó sẽ được coi như
thể nó chứa TLV “các giao thức được hỗ trợ” chỉ chứa NLPID cho CLNP.
DCF sẽ so sánh các NLPID được liệt kê trong “các giao thức được hỗ trợ” TLV (chỉ giả sử CLNP
nếu không có) với các giao thức lớp mạng mà bản thân DCF có khả năng chuyển tiếp.
Nếu không tồn tại gần kề với hàng xóm đã gửi ISH hoặc IIH và nếu DCF không có khả năng
chuyển tiếp bất kỳ giao thức lớp mạng nào được liệt kê trong “các giao thức được hỗ trợ” TLV của
ISH hoặc IIH nhận được từ người hàng xóm, thì DCF sẽ không tạo thành mối quan hệ liền kề với
người hàng xóm đó.
Nếu tồn tại sự gần kề với hàng xóm đã gửi ISH hoặc IIH và nếu DCF không có khả năng chuyển
tiếp bất kỳ giao thức lớp mạng nào được liệt kê trong "Các giao thức được hỗ trợ" TLV của ISH
hoặc IIH nhận được từ hàng xóm, sau đó DCF sẽ xóa gần kề với hàng xóm đó và tạo ra một Giao
thức Sự kiện.
Nếu bản thân DCF có khả năng chuyển tiếp một hoặc nhiều giao thức lớp mạng được liệt kê trong
TLV “giao thức được hỗ trợ” của ISH hoặc IIH đã nhận, thì DCF sẽ xử lý ISH hoặc IIH như bình
thường.
DCF sẽ không xem xét giá trị của TLV “các giao thức được hỗ trợ” của các LSP trong quá trình
này.
Một DCF không thể chuyển tiếp các PDU CLNP sẽ bỏ qua các PDU ESH và do đó sẽ không quảng
cáo khả năng truy cập tới Hệ thống cuối OSI.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
36

A DCF supporting Integrated IS-IS shall not consider itself a neighbor of another node on the same
subnetwork unless the two nodes have at least one network layer protocol in common. This
information is present in the protocol supported TLV of ISIS IIH PDUs as specified in RFC 1195.
The lack of a protocol supported TLV in an ISIS IIH PDU indicates that the DCF only supports
OSI.
7.1.10.1.12 Phân phối tiền tố IP trên toàn miền ISIS
Các DCF hỗ trợ IS-IS tích hợp cấp 1, cấp 2 sẽ hỗ trợ quảng cáo các tiền tố đích IP được cấu hình đã
học qua cấp 2 thành các LSP cấp 1, cũng như các tiền tố đích IP được học qua cấp 1 vào các LSP
cấp 2. Hành vi mặc định, khi không có tiền tố đích IP nào được định cấu hình, sẽ không truyền bất
kỳ tiền tố cấp 2 nào sang các LSP cấp 1, trong khi tất cả các tiền tố đã học Cấp 1 sẽ được truyền
sang các LSP cấp 2.
7.1.10.1.12.1 Tiền tố cấu hình
Người vận hành sẽ cung cấp hai bảng điều khiển việc truyền các tiền tố. Một bảng sẽ điều khiển sự
lan truyền từ Mức-1 đến Mức-2, trong khi bảng kia điều khiển sự lan truyền từ Mức-2 đến Mức-1.
7.1.10.1.12.2 Gắn thẻ các tiền tố được đề xuất
Vì việc truyền tiền tố từ Cấp độ-2 sang Cấp độ-1 và sau đó từ Cấp độ-1 trở lại Cấp độ-2 có thể giới
thiệu các vòng lặp định tuyến, nên cần có thẻ để xác định nguồn của tiền tố. Thẻ này, được gọi là bit
lên / xuống, được lưu trữ trong bit thứ tự cao chưa được sử dụng trước đây (bit 8) của trường Số
liệu mặc định trong TLV khả năng tiếp cận IP và TLV khả năng tiếp cận bên ngoài IP. Việc triển
khai IS-IS hiện có hỗ trợ RFC 1195 sẽ không bị ảnh hưởng bởi việc định nghĩa lại bit này vì RFC
1195 yêu cầu nó phải được đặt thành 0 khi các LSP gốc và bị bỏ qua khi nhận. Thông tin thêm có
sẵn trong RFC 2966.
TLV khả năng tiếp cận IP và TLV khả năng tiếp cận IP bên ngoài sẽ được xử lý trong cùng một
trang viên. Loại TLV nhận được sẽ cùng loại được sử dụng khi tiền tố được truyền từ Vùng-2 sang
vùng Cấp-1, cũng như từ vùng Cấp-1 đến Cấp-2.
Điều này khác với RFC 1195, vốn giới hạn các TLV có khả năng tiếp cận bên ngoài IP chỉ xuất
hiện trong các LSP cấp 2.
7.1.10.1.12.2.1 Truyền LSP với TLV khả năng tiếp cận IP và TLV có khả năng tiếp cận IP bên
ngoài
Như với RFC 1195 thông thường, giá trị của bit lên / xuống sẽ bằng 0 đối với tất cả các IP TLV
trong LSP mức 2. Giá trị của bit lên / xuống sẽ bằng 0 đối với các LSP Mức 1 được bắt nguồn trong
khu vực Mức 1.
Bit lên / xuống sẽ được đặt thành một trong một IP TLV ở LSP cấp-1 khi IS-IS NE tích hợp cấp-1,
cấp-2 đang truyền tiền tố được định cấu hình từ cấp-2 đến cấp-1.
7.1.10.1.12.2.2 Tiếp nhận LSP với TLV khả năng tiếp cận IP và TLV có khả năng tiếp cận IP
bên ngoài
DCF hỗ trợ IS-IS tích hợp sẽ bỏ qua giá trị của bit lên / xuống khi phát triển các tuyến để sử dụng
trong khu vực Cấp 1 hoặc Cấp 2.
DCF hỗ trợ IS-IS tích hợp cấp 1, cấp 2 nhận được LSP với IP TLV cho tiền tố khớp với mục nhập
trong bảng Truyền cấp từ cấp 1 đến cấp 2 sẽ quảng cáo tiền tố thích hợp từ Cấp-1 đến Cấp độ 2.
DCF hỗ trợ IS-IS tích hợp Mức 1, Mức 2 nhận được LSP với IP TLV với bit lên / xuống được đặt
thành một sẽ không bao giờ sử dụng tiền tố để truyền thông tin từ Mức-1 đến Mức-2.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
37

7.1.10.1.12.2.3 Sử dụng bit lên / xuống trong LSP cấp 2


Việc sử dụng bit lên / xuống trong LSP cấp 2 là để nghiên cứu thêm.
7.1.10.1.12.3 Tùy chọn tuyến đường
Do các tiền tố hiện có thể được truyền từ Cấp-2 đến Cấp-1, nên các Tùy chọn Tuyến đường được
chỉ định trong RFC 1195 phải được cập nhật để tính đến nguồn mới này. Thứ tự Sở thích Tuyến
đường kết quả như sau:
1) Các tuyến đường nội khu L1 với chỉ số nội bộL1 các tuyến đường bên ngoài với chỉ số nội bộ

2) Các tuyến đường nội khu L2 với hệ mét bên trongL2 các tuyến đường bên ngoài với hệ mét bên
trong

3) Các tuyến đường giữa khu vực được truyền từ L2 sang khu vực L1 với chỉ số bên trong

4) L1 các tuyến đường bên ngoài với số liệu bên ngoài


5) Các tuyến bên ngoài L2 với số liệu bên ngoài

6) Các tuyến đường bên ngoài liên khu vực được truyền từ L2 sang khu vực L1 với chỉ số bên
ngoài
7.1.11 Chức năng liên kết định tuyến IP
Một DCF hỗ trợ Chức năng Liên kết Định tuyến IP sẽ hỗ trợ các cơ chế lọc định tuyến theo Phần
7.5 và 7.6 của RFC 1812 để các mạng có hai giao thức định tuyến có thể được kết nối qua nhiều
hơn một điểm trao đổi.
7.1.12 [Ứng dụng cho lớp mạng] Chức năng ánh xạ
Các ứng dụng OSI chạy trên (một phần của) DCN chỉ hỗ trợ IP có thể được ánh xạ thành IP như
được chỉ định trong đoạn của Khuyến nghị Q.811 xử lý cấu hình giao thức RFC 1006 / TCP / IP.
Một ánh xạ như vậy là một giải pháp Lớp 4 và do đó nằm ngoài phạm vi của khuyến nghị này. Một
tùy chọn khác để mang các ứng dụng OSI qua (một phần của) DCN chỉ hỗ trợ IP là cung cấp gói
OSI qua IP Lớp 3 như được chỉ định trong Phần 7.1.8.
Việc ánh xạ các ứng dụng IP qua (một phần của) IP hỗ trợ DCN phải phù hợp với các thông số kỹ
thuật của bộ IP.

7.2 Yêu cầu cấp phép


Mọi NE phải hỗ trợ việc tạo ra một giao diện không có bất kỳ biểu hiện vật lý nào. Giao diện này
phải được cung cấp bằng địa chỉ IP.
Kích thước LSP phải có thể định cấu hình.
Điều này cho phép kích thước MTU trong miền được thiết lập.
Cung cấp ID khu vực cho mỗi giao diện, bao gồm các kênh ECC và mạng LAN, là bắt buộc đối với
OSPF.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
38

7.3 Yêu cầu bảo mật


Cần phải cẩn thận để tránh các tương tác không mong muốn (địa chỉ, v.v.) giữa mạng IP công cộng
và IP hỗ trợ DCN.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
39

PHỤ LỤC A

Yêu cầu đối với Bắt tay ba chiều

Quy trình bắt tay ba bước được dựa trên và được thiết kế để tương thích với Nhóm công tác IS-IS
của IETFChức năng Bắt tay Ba chiều.

A1 Point-to-Point TLV liền kề ba chiều


DCF hỗ trợ IS-IS tích hợp sẽ bao gồm TLV trong tất cả các PDU IIH điểm-điểm. Cấu trúc của TLV
sẽ là:
A new IS-IS Option type, "Point-to-Point Adjacency State", must be supported by a DCF that
routes IP using Integrated IS-IS as defined below:

Gõ = 0xF0 (thập phân 240)


Chiều dài = 5 đến 17 octet
Giá trị:
Sự gần gũi Ba cách Trạng thái (một octet):
0 = Lên
1 = Khởi tạo
2 = Xuống
ID mạch cục bộ mở rộng của bốn octetNS (four octets)
ID hệ thống lân cận từ 0 đến 8 octet Nêu biêt được (zero to eight octets)
ID mạch cục bộ mở rộng lân cận của bốn octet nếu biết (four octets, if Neighbor System ID is
present)

ID mạch cục bộ mở rộng sẽ được DCF ấn định khi tạo mạch và DCF sẽ sử dụng một giá trị khác
nhau cho mỗi mạch điểm-điểm mà nó có.
Trạng thái ba chiều gần kề được báo cáo trong TLV sẽ được quy định trong Phần A2.

A2 Trạng thái ba chiều gần kề


DCF hỗ trợ IS-IS tích hợp cho mỗi mạch điểm-điểm phải có trạng thái ba chiều kề nhau. Trạng thái
này khác với trạng thái được quy định trong ISO / IEC 10589.
Nếu không có cạnh nào tồn tại trên một liên kết thì trạng thái ba chiều kề sẽ được đặt thành
“Xuống”.
Nếu một DCF nhận được ISH trên một liên kết điểm-điểm và điều này dẫn đến một lần gần kề mới
được tạo với trạng thái kề “Đang khởi tạo”, thì trạng thái ba chiều gần kề sẽ được đặt thành
“Xuống”.
Nếu một DCF nhận được một điểm-điểm IIH không chứa TLV liền kề ba chiều, thì DCF phải hoạt
động theo ISO / IEC 10589, nhưng phải bao gồm TLV trong IIH PDU trên liên kết đó báo cáo trạng
thái ba chiều gần kề là "Xuống".

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
40

Nếu DCF nhận PDU IIH điểm-điểm có chứa TLV kề ba chiều, thì DCF sẽ hoạt động khác với xử lý
PDU ISO / IEC 10589 IIH như sau:
Nếu các trường ID hệ thống lân cận và ID mạch cục bộ mở rộng lân cận của TLV hiện có và
nếu ID hệ thống lân cận không khớp với ID của DCF hoặc ID mạch cục bộ mở rộng lân cận
không khớp với ID mở rộng của DCF, thì IIH PDU sẽ bị loại bỏ và sẽ không được xử lý.
Nếu kết quả của IIH PDU trong các bảng trạng thái ISO / IEC 10589 tạo ra một “Lên” hoặc
“Chấp nhận” và nếu Trạng thái ba chiều gần kề nhận được là “Xuống”, thì DCF sẽ đặt trạng
thái ba chiều gần kề của nó thành “Đang khởi tạo”.
Nếu IIH PDU dẫn đến các bảng trạng thái ISO / IEC 10589, thì kết quả là "Tăng" hoặc
“Chấp nhận” và nếu Trạng thái ba chiều lân cận nhận được là “Đang khởi tạo”, thì DCF sẽ
thay đổi trạng thái ba chiều lân cận từ “Xuống” hoặc “Bắt đầu” thành “Lên” và tạo sự kiện
“AdjacencyChangeState (Lên)”.
Nếu kết quả của IIH PDU trong các bảng trạng thái ISO / IEC 10589 tạo ra một “Lên” hoặc
“Chấp nhận” và nếu Trạng thái ba chiều gần kề nhận được là “Đang khởi tạo”, thì nếu NS
DCF đã có trạng thái ba chiều gần kề là "Lên", nó nên duy trì trạng thái ba chiều liền kề của
“Lên”.
Nếu IIH PDU dẫn đến các bảng trạng thái ISO / IEC 10589 tạo ra “Lên” hoặc “Chấp nhận”
và nếu Trạng thái ba chiều gần kề nhận được là “Tăng”, thì nếu DCF đã có trạng thái ba
chiều kề là “Xuống”, nó sẽ tạo ra sự kiện “AdjacencyStateChange (Xuống)” với lý do
“Vùng lân cận đã khởi động lại” và thời gian liền kề sẽ bị xóa mà không có quá trình xử lý
IIH PDU nào diễn ra.
Nếu kết quả của IIH PDU trong các bảng trạng thái ISO / IEC 10589 tạo ra một “Lên” hoặc
“Chấp nhận” và nếu Trạng thái ba chiều gần kề nhận được là “Lên”, thì nếu DCF đã có
trạng thái ba chiều kề là “Đang khởi tạo”, thì nó sẽ thay đổi trạng thái ba chiều kề cận thành
"Hướng lên”Và tạo sự kiện“ AdjacencyChangeState (Up) ”.
Nếu kết quả của IIH PDU trong các bảng trạng thái ISO / IEC 10589 tạo ra một “Lên” hoặc
“Chấp nhận” và nếu Trạng thái ba chiều gần kề nhận được là “Tăng”, thì nếu DCF đã có
trạng thái ba chiều gần kề là “Lên”, thì nên duy trì trạng thái ba chiều liền kề của "Hướng
lên".
Theo sau the so sánh ID nguồn từ PDU với ID hệ thống cục bộ và thao tác của mạch ID sẽ
không được thực hiện.
Nếu kết quả của IIH PDU trong các bảng trạng thái ISO / IEC 10589 tạo ra “Lên” hoặc “Chấp
nhận” thì DCF phải:
1. sao chép vùng kề cận các mục nhậpAddressOfNeighbour từ trường Địa chỉ vùng của PDU,
2. đặt giá trị holdTimer của trường Thời gian giữ từ PDU và
3. đặt NeighbourSystemID thành giá trị của trường ID nguồn từ PDU
theo ISO / IEC 10589.
Any DCF that routes IP using Integrated IS-IS shall include this option in its Point-to-Point IIH
packets.
A DCF that only routes OSI may or may not understand this option and if not will ignore it, and
will not include it in its own IIH packets.
All DCFs that support IP, and OSI-only DCFs that are able to process this option, shall follow the
procedures below.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
41

Elements of Procedure
The new handshake procedure is added to the IS-IS point-to-point IIH state machine after the PDU
acceptance tests have been performed.
The existing procedures are only executed if the neighbor is in the proper state for the adjacency to
come up.
Although the extended circuit ID is only used in the context of the three-way handshake, it is worth
noting that it effectively protects against the unlikely event where a link is moved to another
interface on a system that has the same local circuit ID, as the received PDUs will be ignored (via
the checks defined below) and the existing adjacency will fail.
The IS shall include the Point-to-Point Adjacency State option in the transmitted Point-to-Point IIH
PDU. The current state of the adjacency with its neighbor on the link (as defined in section 8.2.4.1
of ISO/IEC 10589) shall be reported in the Adjacency State field. If no adjacency exists, the state
shall be reported as Down.
The Extended Local Circuit ID field shall contain a value assigned by this IS when the circuit is
created. This value shall be unique among all the circuits of this Intermediate System. The value is
not necessarily related to that carried in the Local Circuit ID field of the IIH PDU.
If the system ID and Extended Local Circuit ID of the neighboring system are known (in state
Initializing or Up), the neighbor's system ID shall be reported in the Neighbor System ID field, and
the neighbor's Extended Local Circuit ID shall be reported in the Neighbor Extended Local Circuit
ID field.
A received Point-to-Point IIH PDU may or may not contain the Point-to-Point Adjacency State
option. If it does not, the link is assumed to be functional in both directions, and the procedures
described in section 8.2.4.2 of ISO/IEC 10589 are followed.
If the option is present, the Neighbor System ID and Neighbor Extended Local Circuit ID fields, if
present, shall be examined.
If they are present, and the system ID contained therein does not match the local system's ID, or the
extended circuit ID does not match the local system's extended circuit ID, the PDU shall be
discarded and no further action is taken.
If the Neighbor System ID and Neighbor Extended Local Circuit ID fields match those of the local
system, or are not present, the procedures described in section 8.2.4.2 of ISO/IEC 10589 are
followed with following changes:
a) In section 8.2.4.2 a and b of ISO/IEC 10589, the action "Up" from state tables 5, 6, 7 and
8 may create new adjacency but the state of the adjacency will be Down.
b) If the action taken from section 8.2.4.2 a or b of ISO/IEC 10589 is "Up" or "Accept", the
IS shall perform the action indicated by the new state table below, based on the current
adjacency state and the received state value from the option. (Note that the procedure works
properly if neither field is ever included. This provides backward compatibility to earlier
versions of three way handshaking.)

Received State
Down Initializing Up
-------------------------------------------------
Down | Initialize Up Down
|

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
42

Adj Initializing | Initialize Up Up


State |
Up | Initialize Accept Accept

If the new action is "Down", an adjacencyStateChange(Down) event is generated with the reason
"Neighbor restarted" and the adjacency shall be deleted.
If the new action is "Initialize", the adjacency state shall be set to "Initializing".
If the new action is "Up", an adjacencyStateChange(Up) event is generated.
c) Skip section 8.2.4.2 c and d of ISO 10589.
d) If the new action is "Initialize", "Up" or "Accept", follow section 8.2.4.2 e of ISO/IEC
10589.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
43

PHỤ LỤC B

Yêu cầu đối với đóng gói tự động

B1 Giới thiệu
Tài liệu này cung cấp đặc điểm kỹ thuật cho Chức năng làm việc liên tục cho phép các nút hỗ trợ
định tuyến các giao thức lớp mạng không tương thích khác nhau, chẳng hạn như CLNS, IPv4 hoặc
IPv6 có mặt trong một khu vực IS-IS cấp 1 hoặc tên miền phụ cấp 2 và tự động truyền một giao
thức lớp mạng này qua một giao thức lớp khác theo yêu cầu, với điều kiện là tất cả các nút đều hỗ
trợ định tuyến IS-IS hoặc IS-IS tích hợp.

B2 Phạm vi
Đề xuất này chỉ áp dụng cho các giao thức có trong các kênh DCC nhúng được tìm thấy trong tín
hiệu điện và quang SDH / SONET. Nó không nhất thiết áp dụng cho các bộ định tuyến không phải
SDH / SONET có thể được sử dụng giữa các máy trạm quản lý và mạng SONET / SDH - cái có thể
được gọi là DCN 'bên ngoài' hoặc 'truy cập'. Tuy nhiên, có thể một bộ định tuyến có thể được kết
nối trực tiếp với mạng SDH / SONET và có thể chạy IS-IS Tích hợp và hoạt động như một Chức
năng làm việc xen kẽ thay vì một nút SDH / SONET. Trong trường hợp này, bộ định tuyến bên
ngoài thực sự trở thành một phần của mạng DCC và tài liệu này áp dụng cho nó.

B3 Các định nghĩa


 Chức năng InterWorking
Chức năng InterWorking là một chức năng cho phép một nút kết nối cả với các nút OSI và với
các nút IP. Nó cũng cho phép một nút chuyển tiếp và nhận các gói CLNS qua các nút có khả
năng IP bằng cách sử dụng đóng gói RFC 1702 và / hoặc chuyển tiếp và nhận các gói IP qua các
nút có khả năng OSI bằng cách sử dụng đóng gói RFC 3147.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
44

 Nút chỉ IP
Nút chỉ IP là nút có thể định tuyến các gói IP trên bất kỳ cổng nào chứ không phải các gói
CLNS. Thuật ngữ này không xác định gói IP là IPv4 hay IPv6.
 Nút chỉ dành cho OSI
Một nút chỉ dành cho OSI là một nút có thể định tuyến các gói CLNS trên bất kỳ cổng nào chứ
không phải các gói IP.
 Nút có khả năng IP
Một nút có khả năng IP là một nút có thể định tuyến các gói IP trên bất kỳ cổng nào và cũng có
thể có hoặc không thể định tuyến các gói CLNS. Thuật ngữ này không xác định gói IP là IPv4
hay IPv6.
 Nút có khả năng OSI
Một nút có khả năng OSI là một nút có thể định tuyến các gói CLNS trên bất kỳ cổng nào và
cũng có thể định tuyến các gói IP.
 Nút kép
Nút kép là một nút có thể định tuyến nguyên bản hai giao thức lớp mạng trên bất kỳ cổng nào.
Thuật ngữ này thường được sử dụng để chỉ một nút định tuyến cả CLNS và IPv4, hoặc một nút
định tuyến cả IPv4 và IPv6.
 Nút đa ngôn ngữ
Nút đa ngôn ngữ là một nút có thể định tuyến tự nhiên hai hoặc nhiều giao thức lớp mạng trên
bất kỳ cổng nào.
 Chia nút ngăn xếp
Nút ngăn xếp phân tách là một nút khởi tạo và kết thúc các gói của một giao thức lớp mạng nội
bộ mà không có sẵn trên các kênh DCC của nó.

B4 Viết tắt
Dịch vụ mạng CLNSConnectionLess mode
Đơn vị dữ liệu giao thức trạng thái LSPLink
Giao thức IPInternet
Hệ thống ISInter Instant
Hệ thống IS-ISInter ngay đến Hệ thống Trung gian
Bộ truyền MTUMaximum
OSIOpen Systems Intercoonect
Đơn vị dữ liệu giao thức PDUP
NLPID Mã định danh giao thức mạng lớp
Điểm truy cập dịch vụ mạng NSAP
Mã định danh hệ thống SIDS
SPFShortest Path First
Giá trị độ dài TLVType

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
45

B5Tài liệu tham khảo


[1] RFC 1195 http://www.ietf.org/rfc/rfc1195.txt
[2] ISO / IEC 10589
[3] RFC 1702 http://www.ietf.org/rfc/rfc1702.txt
[4] RFC 3147 http://www.ietf.org/rfc/rfc3147.txt
[5] ISO / IEC 9542
[6] ISO 9577 hoặc ITU-T X.263
[7] ITU-T G.7712

B6Discussion

B6.1 Giới thiệu


IS-IS tích hợp như được chỉ định trong RFC 1195 [1] ban đầu được thiết kế để có thể định tuyến IP
và CLNS bằng cách sử dụng một giao thức định tuyến và một thuật toán SPF duy nhất. Đối với điều
này, nó đại diện cho địa chỉ IPv4 và mặt nạ mạng con dưới dạng số 64 bit, sau đó được thuật toán
SPF xử lý như thể nó là địa chỉ Hệ thống cuối OSI. Các nút IS-IS tích hợp bắt buộc phải có Địa chỉ
vùng IS-IS và Số nhận dạng hệ thống, được xử lý theo cách giống như địa chỉ NSAP trong nút chỉ
dành cho OSI. Sau đó, các nút IS-IS được tích hợp tạo thành các vùng bổ trợ và ngập lụt Số nhận
dạng hệ thống và chỉ số trong toàn bộ khu vực cấp 1 của chúng (bộ định tuyến cấp 1) hoặc miền
phụ cấp 2 (bộ định tuyến cấp 2) theo cách tương tự như các nút IS-IS chỉ dành cho OSI .
SID (Số nhận dạng hệ thống) và các chỉ số cho các SID khác bị tràn ngập trong khu vực cấp 1 hoặc
miền phụ cấp 2 bằng cách sử dụng LSP (Liên kết trạng thái PDU) phổ biến cho cả nút IS-IS và IS-
IS tích hợp. Thông tin cụ thể về IP sau đó được thêm vào các LSP này bằng cách sử dụng phần mở
rộng TLV mà chỉ các nút có khả năng IP mới hiểu được. Các bộ định tuyến chỉ dành cho OSI không
thể giải mã các TLV này nhưng vẫn làm ngập chúng trở đi cho tất cả các vùng phụ cận của chúng.
Theo cách này, cây SPF có thể được xây dựng bởi bất kỳ nút IS-IS hoặc IS-IS tích hợp nào cho dù
nó có thể định tuyến CLNS, IPv4 hay IPv6. Các nút hỗ trợ OSI sẽ tính toán đường dẫn ngắn nhất
đến Hệ thống cuối OSI, các nút hỗ trợ IPv4 sẽ tính toán đường dẫn ngắn nhất đến địa chỉ hoặc tiền
tố IPv4 và các nút hỗ trợ IPv6 sẽ tính toán đường dẫn ngắn nhất đến địa chỉ hoặc tiền tố IPv6.
Một hệ quả của điều này là nút chỉ dành cho OSI sẽ tính toán đường đi ngắn nhất đến Hệ thống cuối
OSI đi qua nút chỉ IP, mặc dù nút chỉ IP đó không thể chuyển tiếp các gói CLNS. Tương tự, nút chỉ
IP sẽ tính toán đường đi ngắn nhất đến đích IP đi qua nút chỉ dành cho OSI, mặc dù nút chỉ dành
cho OSI không thể chuyển tiếp các gói IP. Do đó, một nút chỉ có khả năng sử dụng OSI không được
đặt trong một phần của mạng nơi có khả năng nó nằm trên đường ngắn nhất đến các đích IP và một
nút chỉ IP không được đặt trong một phần của mạng nơi có khả năng nó nằm trên đường ngắn nhất
đến Hệ thống cuối OSI.
Thuật toán IS-IS tích hợp chỉ có thể sử dụng một thuật toán SPF duy nhất cho hai hoặc nhiều giao
thức lớp mạng do giả định rằng tất cả các giao thức lớp mạng đều có quyền truy cập vào cùng một
tài nguyên, nói cách khác là cùng một mạng với cùng một cấu trúc liên kết. Do đó, IS-IS tích hợp
yêu cầu bất kỳ nút nào trong khu vực cấp 1 hoặc miền phụ cấp 2 để có thể định tuyến bất kỳ giao
thức lớp mạng nào có mặt trong khu vực hoặc miền tương ứng.
Vì lý do này, RFC 1195 [1] đặt ra các hạn chế về cấu trúc liên kết trên các mạng được định tuyến
bởi IS-IS tích hợp, yêu cầu tất cả các nút hỗ trợ cả IP và CLNS trong một khu vực có cả lưu lượng
CLNS và lưu lượng IP trong đó.
Do đó, theo RFC 1195 [1], nếu một nút được nâng cấp và chuyển tiếp các gói IP, thì tất cả các nút

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
46

khác trong khu vực cấp 1 hoặc miền phụ cấp 2 cũng phải được nâng cấp.
Giải pháp được đề xuất ở đây cho phép loại bỏ hạn chế tôpô này và nó tự động đóng gói các gói
CLNS bên trong các gói IP để chuyển tiếp qua các nút chỉ IP và đóng gói các gói IP bên trong các
gói CLNS để chuyển tiếp qua các nút chỉ dành cho OSI. Giải pháp được đề xuất ở đây hoàn toàn
tương thích với các nút chỉ dành cho OSI hiện có, sẽ không yêu cầu bất kỳ nâng cấp nào. Nó đặt ra
một yêu cầu đối với các nút chỉ IP cao hơn các nút trong RFC 1195 [1], nhưng bắt buộc phải có mặt
trên tất cả các bộ định tuyến IP và OSI kép hoặc đa ngôn ngữ trong khu vực cấp 1 hoặc miền phụ
cấp 2 sử dụng giải pháp. Các bộ định tuyến kép hỗ trợ tính năng này vẫn có thể được đặt trong khu
vực cấp 1 hoặc miền phụ cấp 2 với các nút IS-IS tích hợp khác không hỗ trợ tính năng này, nhưng
trong trường hợp này, các hạn chế về cấu trúc liên kết của RFC 1195 [1] sau đó sẽ vẫn áp dụng.

B6.2 Khái niệm cơ bản


Tính năng này tận dụng lợi thế của thực tế là tất cả các nút IS-IS và IS-IS tích hợp chia sẻ thông tin
cấu trúc liên kết cơ bản theo cùng một cách và hành vi mà các nút chỉ dành cho OSI sẽ cố gắng
chuyển tiếp một gói qua một nút chỉ IP và nút khác. ngược lại, mặc dù nút đó không có khả năng
thực sự chuyển tiếp gói tin. Thông thường, điều này sẽ dẫn đến mất gói, nhưng Chức năng
InterWorking này dẫn đến các gói được đóng gói trước khi được chuyển tiếp qua các nút không
tương thích chứ không phải bị mất.
Khi hai hòn đảo có khả năng IP Các nút IS-IS tích hợp được kết nối bằng cách sử dụng mạng trung
tâm chỉ hỗ trợ OSI và nếu tất cả các nút tham gia vào cùng một khu vực (đối với các nút cấp 1), thì
các nút có khả năng IP sẽ nhận được các LSP từ tất cả các nút có khả năng IP khác, ngay cả những
nút ở đảo khác, cũng như các LSP từ tất cả các nút chỉ dành cho OSI ở giữa. Do đó, họ tính toán các
đường đi ngắn nhất qua các nút chỉ dành cho OSI cho tất cả các điểm đến IP ở hòn đảo ở phía xa.
Chỉ khi một nút có khả năng IP thực sự chuyển tiếp một gói IP tới một nút chỉ dành cho OSI thì mọi
thứ mới xảy ra sự cố và gói bị mất. Do đó các hạn chế về cấu trúc liên kết trong RFC 1195 [1].

Các mạng đơn giản ở trên là cấu trúc liên kết bất hợp pháp theo RFC 1195 [1]. Trong mạng trên
cùng, các gói IP sẽ được định tuyến từ bên này sang bên kia của mạng, nhưng khi đến nút chỉ dành
cho OSI sẽ bị loại bỏ. Tương tự trên mạng dưới cùng, các gói CLNS sẽ được định tuyến từ bên này
sang bên kia của mạng, nhưng khi đến nút chỉ IP sẽ bị loại bỏ. Chức năng InterWorking được chỉ
định ở đây sẽ sửa hành vi này.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
47

Chức năng InterWorking này nằm trong các nút kép và cho phép chúng nhận ra rằng một hàng xóm
cụ thể sẽ loại bỏ một số lưu lượng nhất định và do đó, đóng gói nó thành một dạng sẽ không bị loại
bỏ. Điều này 'sửa chữa' mạng để một phần của mạng giữa các nút kép hoạt động như thể nó bao
gồm tất cả các nút kép, trong khi trên thực tế, một hoặc nhiều nút không phải là nút kép.
Chức năng InterWorking này không làm thay đổi đường dẫn mà một gói tin sẽ đi qua mạng; bất kỳ
gói riêng lẻ nào vẫn sẽ qua mạng bằng cách sử dụng đường dẫn ngắn nhất như được tính toán bởi
thuật toán IS-IS SPF thông thường.
Chức năng InterWorking này thực hiện hai điều cơ bản. Thứ nhất, nó buộc lưu lượng truy cập phải
đi qua các nút hỗ trợ cả IP và OSI bất cứ khi nào con đường ngắn nhất đưa lưu lượng qua ranh giới
giữa các phần có khả năng IP và có khả năng OSI của một khu vực. Thứ hai, nó buộc các nút kép
đó đóng gói một gói nếu cần thiết để nó có thể được chuyển tiếp bởi các nút không hỗ trợ giao thức
lớp mạng đó. Việc đóng gói này chỉ diễn ra khi cần thiết và do đó các đường hầm này được tạo tự
động và có tính năng động. Các đường hầm không được duy trì theo bất kỳ cách nào và chỉ tồn tại
dưới dạng các mục nhập trong bảng chuyển tiếp. Cuối cùng vì các gói vẫn đi qua mạng theo đường
ngắn nhất mà mỗi nút tính toán bình thường và vì tất cả các nút đều có chung một giao thức định
tuyến cơ bản, nên không cần các gói IS-IS đi qua các đường hầm này,

B6.3 Yêu cầu đối với các nút chỉ dành cho OSI
Các nút chỉ dành cho OSI được yêu cầu phải phù hợp với ISO / IEC 10589 [2].

B6.4 Yêu cầu đối với các nút hỗ trợ IP


Các nút chỉ IP được yêu cầu tuân theo RFC 1195 [1].
Đặc biệt, các nút có khả năng IP được yêu cầu bỏ qua TLV “được hỗ trợ giao thức” trong LSP của
các nút mà chúng đang coi là ứng cử viên cho đường dẫn ngắn nhất khi chạy thuật toán SPF.
Một nút có khả năng IP chỉ bao gồm các nút có khả năng IP trong tính toán SPF của nó không tuân
theo RFC 1195 [1], trong đó nó tuyên bố: -

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
48

Từ trang 26 của RFC 1195 [1]: “Tính toán Dijkstra không xem xét liệu một bộ định tuyến là chỉ
IP, chỉ OSI hay kép. Các hạn chế cấu trúc liên kết được chỉ định trong phần 1.4 đảm bảo rằng
các gói IP sẽ chỉ được gửi qua các bộ định tuyến hỗ trợ IP và các gói OSI sẽ chỉ được gửi qua
các bộ định tuyến hỗ trợ OSI. ”
Chức năng InterWorking được mô tả trong tài liệu này tương thích với các triển khai RFC 1195
tuân theo tuyên bố trên. Việc triển khai chỉ bao gồm các nút có khả năng IP trong tính toán SPF của
nó sẽ không xem các đường hầm được tạo tự động là một tuyến đường phù hợp và do đó sẽ không
tận dụng được Chức năng Làm việc Liên hợp này.
Một yêu cầu ngoài RFC 1195 [1] được mô tả dưới đây: -
Giải pháp này phụ thuộc vào việc các gói IP đến một nút chỉ dành cho OSI chỉ đi qua một nút kép
đầu tiên và khi các gói CLNS đến một nút chỉ IP chỉ đi qua một nút kép đầu tiên. Các nút kép này
sau đó chịu trách nhiệm đóng gói các gói này để chúng có thể được chuyển tiếp.
Do đó, một nút chỉ IP phải không bao giờ có sự liền kề với một nút chỉ dành cho OSI.
Nếu giải pháp này được sử dụng để kết hợp các nút IPv4 và IPv6 trong cùng một khu vực cấp 1
hoặc miền phụ cấp 2 thì tương tự như vậy, một nút chỉ IPv4 không bao giờ được có một phần kề với
nút chỉ IPv6.
Do đó, các nút IS-IS tích hợp được yêu cầu để kiểm tra xem một nút lân cận có hỗ trợ giao thức lớp
mạng mà chúng hỗ trợ hay không. Nếu không có lớp mạng nào mà cả hai nút đều hỗ trợ chung, thì
nút đó phải từ chối sự kề cận.
IS-IS tích hợp yêu cầu tất cả Hello PDU phải chứa TLV “được hỗ trợ giao thức”. TLV nàycần phải
được kiểm tra bởi các nút phù hợp với tài liệu này và nếu không có lớp nào trong số các lớp mạng
mà nút hỗ trợ được liệt kê, thì nút cần phảitừ chối sự điều chỉnh. Sự vắng mặt của “các giao thức
được hỗ trợ” TLV trong Hello PDU chỉ ra rằng nút lân cận là nút chỉ dành cho OSI.
Yêu cầu này đã được giải quyết trong phiên bản G.7712 hiện tại trong phần 7.1.10.1
Ngoài ra, một nhà điều hành có thể đảm bảo theo cách thủ công rằng các nút không hỗ trợ giao thức
lớp mạng nói chung không có các nút bổ sung.

B6.5 Yêu cầu tự động đóng gói các nút kép hoặc đa ngôn ngữ
Nếu tính năng này được sử dụng trong khu vực cấp 1 hoặc tên miền phụ cấp 2 thì các nút hỗ trợ
nhiều hơn một giao thức lớp mạng, nhưng không có Tính năng làm việc xen kẽ này có thểđược sử
dụng một cách thận trọng. Một giải pháp thay thế an toàn hơn là tuân thủ các giới hạn cấu trúc liên
kết của RFC 1195 hoặc chỉ sử dụng các nút kép hoặc đa ngôn ngữ có chứa Chức năng làm việc liên
kết này.

B6.5.1 Khả năng đóng gói TLV


Các nút kép hoặc đa ngôn ngữ hỗ trợ Chức năng InterWorking này sẽ bao gồm một TLV mới trong
các LSP có số LSP bằng 0. TLV mới sẽ có cấu trúc sau: -
Mã: 16 (thập phân)
Chiều dài: Chiều dài của giá trị
Giá trị: Một phần có độ dài thay đổi có chứa thông tin sau: -
Loại TLV phụ: 1
Độ dài TLV phụ: gấp 3 lần số chế độ đóng gói trong TLV phụ

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
49

Giá trị TLV phụ: -


47 chỉ ra rằng hai byte tiếp theo là cách đóng gói GRE
NLPID của một gói có thể được đóng gói (bên trong)
NLPID của gói truyền tải gói được đóng gói (bên ngoài)
Byte 4,5,6: Chế độ đóng gói thứ hai (nếu cần)
Byte 7,8,9: Chế độ đóng gói thứ ba (nếu cần)
Vân vân.
NLPID được sử dụng SẼ là những NLPID được quy định trong ISO 9577 [6]. Các nút truyền TLV
SHALL này cho biết các định dạng mà một nút có thể nhận và truyền. Điểm giaocần phải có thể tự
động đóng gói và tự động đóng gói các định dạng được mô tả trong TLV, để lưu lượng truy cập có
thể được nhận và lưu lượng truy cập có thể quay trở lại theo hướng ngược lại.
Khuyến nghị rằng các nút kép có thể đóng gói / không đóng gói A trên B và B trên A (trong đó A
và B là hai giao thức lớp mạng được hỗ trợ) tạo ra hai chế độ đóng gói trong một nút kép điển hình.
Ví dụ, nội dung của TLV cho một nút kép OSI và IPv4 điển hình sẽ là: -
16: mã
8: độ dài giá trị (trong ví dụ này)
1: sub-TLV loại 1
6: độ dài TLV phụ (trong ví dụ này)
47: hai byte tiếp theo là chế độ GRE được hỗ trợ
129: IPI cho CLNP từ ISO 9577
204: IPI cho IPv4 từ ISO 9577
47: hai byte tiếp theo là chế độ GRE được hỗ trợ
204: IPI cho IPv4 từ ISO 9577
129 IPI cho CLNP từ ISO 9577
Do đó, một nút ba ngôn ngữ OSI, IPv4, IPv6 thường sẽ sử dụng sáu chế độ đóng gói để chỉ ra
CLNP qua IPv4, CLNP qua IPv6, IPv4 qua CLNS, IPv4 qua IPv6, IPv6 qua CLNS và IPv6 trên
IPv4, cho độ dài giá trị là 20.
TLV này sẽ không được bao gồm trong các LSP giả điện tử.
Một nút kép không có bất kỳ địa chỉ IPv4 nào cần phải không phải đặt bất kỳ định dạng đóng gói
nào trong TLV của nó thuộc loại 16 bao gồm IPv4 như một NLPID vận chuyển đóng gói (bên
ngoài) cho đến khi địa chỉ IPv4 được cung cấp và quảng cáo.
Một nút kép không có bất kỳ địa chỉ IPv6 nào cần phải không phải đặt bất kỳ định dạng đóng gói
nào trong TLV của nó thuộc loại 16 bao gồm IPv6 như một NLPID vận chuyển đóng gói (bên
ngoài) cho đến khi địa chỉ IPv6 được cung cấp và quảng cáo.

B6.5.2 Quy trình chuyển tiếp


Vì Hàm InterWorking này không sửa đổi đường dẫn mà một gói đi theo, một nút kép hoặc đa ngôn
ngữ có thể tính toán đường đi ngắn nhất cho gói IP dẫn đến bước tiếp theo là nút chỉ dành cho OSI.
Khi điều này xảy ra, nút kép hoặc nút đa ngôn ngữ cần phải không phảichỉ cần chuyển tiếp một gói
đến một nút liền kề không hỗ trợ loại giao thức lớp mạng đó. Thay vào đó là nút kép hoặc đa ngôn
ngữcần phảiđóng gói gói bên trong một gói mới của loại mà bước tiếp theo hỗ trợ. Tiêu chí cho việc
một nút liền kề có hoặc không hỗ trợ một giao thức lớp mạng cụ thể hay không là liệu giao thức lớp
mạng đó có được liệt kê trong TLV “các giao thức được hỗ trợ” trong IS-IS Hello PDU nhận được
từ nút trên kề đó là bước tiếp theo hay không cho điểm đến đó.
Gói mới này yêu cầu một giao thức lớp mạng, một địa chỉ đích và một địa chỉ nguồn để đóng gói

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
50

gói ban đầu.


Giao thức lớp mạng của gói mới cần phải được hỗ trợ bởi bước tiếp theo như được định nghĩa bởi
"các giao thức được hỗ trợ" TLV của Hello PDUs nhận được từ bước tiếp theo.
Địa chỉ đích của gói tin mới cần phải bằng với nhận dạng của nút tiếp theo dọc theo đường ngắn
nhất đến đích ban đầu đã truyền một chế độ đóng gói có cả loại giao thức lớp mạng mà gói ban đầu
là NLPID được đóng gói (bên trong) và một giao thức lớp mạng được hỗ trợ bởi bước tiếp theo
(như được định nghĩa bởi “giao thức được hỗ trợ” TLV của Hello PDU nhận được từ bước tiếp
theo) dưới dạng NLPID vận chuyển đóng gói (bên ngoài).
Cái này cần phải đạt được bằng cách kiểm tra TLV mới có loại bằng 16 từ các LSP nhận được từ
mỗi nút trong đường dẫn đến đích, cho đến khi tìm thấy nút đầu tiên đáp ứng yêu cầu trên.
Khi kiểm tra các TLV có kiểu bằng 16, một nút SẼ bỏ qua bất kỳ TLV con nào mà nó không hiểu,
và sẽ chuyển sang TLV con tiếp theo và SHALL sẽ kiểm tra điều đó, cho đến khi nó tìm thấy tất cả
các chế độ đóng gói mà nó đang tìm kiếm. cho hoặc cho đến khi kết thúc TLV.
Địa chỉ nguồn của gói tin mới cần phải bằng danh tính của nút xây dựng gói đóng gói mới.
Nếu một nút kép hoặc nút đa ngôn ngữ có thể chuyển tiếp một gói mà không cần đóng gói vì bước
tiếp theo hỗ trợ loại gói đó, thì nút kép hoặc đa ngôn ngữ cần phải chuyển tiếp gói tin mà không cần
đóng gói nó.
Một nút kép hoặc đa ngôn ngữ có thể gửi các LSP có chứa khả năng truy cập IP từ một nút chỉ IP
đến một nút ngăn xếp phân tách hoặc ngược lại, và do đó có thể được yêu cầu đóng gói các gói
hướng đến một nút ngăn xếp phân tách hoặc bỏ đóng gói các gói nhận được từ một phân tách nút
ngăn xếp.
Do đó, một nút ngăn xếp phân tách cũng phải tuân theo cùng một quy trình kiểm tra LSP của các
nút giữa chính nó và đích tìm kiếm một nút có định dạng đóng gói phù hợp.
Lưu ý rằng một nút ngăn xếp phân tách có thể nhận một gói IPv4 chỉ được đóng gói bên trong
CLNS chẳng hạn. Trong trường hợp này, nút ngăn xếp phân tách sẽ chỉ truyền “CLNS” trong
trường “giao thức được hỗ trợ” của gói Hello và sẽ chỉ bao gồm một chế độ đóng gói trong TLV
của nó thuộc loại 16 trong các LSP của nó. Chế độ đóng gói đơn này sẽ chỉ định IPv4 là gói NLPID
được đóng gói (bên trong) và CLNS là gói NLPID vận chuyển đóng gói (bên ngoài).

B6.5.3 Quy trình nhận


Khi một nút kép hoặc nút đa ngôn ngữ nhận được một gói tin dành riêng cho chính nó, nó cần
phảikiểm tra gói tin đó để xem nó có gói tin khác được đóng gói bên trong hay không. Kết quả là
gói CLNS, IPv4 hoặc IPv6 không được đóng góicần phảisau đó được chuyển tiếp như bình thường.
Nếu kết quả là gói chưa được đóng gói chứa một gói khác dành cho nút này thì quá trình sẽ lặp lại;
điều này là do nhiều lớp đóng gói có thể yêu cầu không đóng gói tại một nút duy nhất.
Các gói IS-IS không tương thích với các gói IP và không thể được chuyển tiếp qua Internet công
cộng hoặc các mạng chỉ IP khác. Đây là một lợi thế bảo mật vì nó gây khó khăn cho một thực thể
độc hại khởi chạy từ xa các gói IS-IS tại các nút IS-IS hoặc IS-IS tích hợp trên Internet công cộng.
Để không loại bỏ lợi thế này, khi đó, nếu một gói IS-IS hoặc ES-IS đến được đóng gói bên trong
một gói khác dành cho một nút thì nút đócần phảiloại bỏ nó, trừ khi nó đến từ một nút mà nút này
có một đường hầm được cấp phép thủ công với IS-IS được cung cấp để chạy qua nó. Theo tùy
chọn, một báo cáo lỗi có thể được đưa ra để thông báo cho người quản lý mạng thông tin như một
gói đã được nhận và bị rơi, nó đến từ đâu hoặc đó là một sự kiện nguy hiểm tiềm ẩn.
Tất cả các nút kép hoặc đa ngôn ngữ trong khu vực cấp 1 hoặc miền phụ cấp 2 cần phảihỗ trợ đóng
gói GRE như được chỉ định trong G.7712. Do đó, một nút kép hoặc đa ngôn ngữ hỗ trợ OSI và

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
51

IPcần phải hỗ trợ đóng gói và bỏ đóng gói các gói CLNS bằng cách sử dụng RFC 1702 [3] và cần
phảihỗ trợ đóng gói và bỏ đóng gói các gói IP sử dụng RFC 3147 [4]. Nút kép hoặc đa ngôn ngữ hỗ
trợ IPv4 và IPv6 phải hỗ trợ đóng gói và bỏ đóng gói các gói IP bằng RFC 1702 [3] để đóng gói
IPv6 bên trong IPv4 hoặc IPv4 bên trong IPv6.

B6.5.4 Yêu cầu về kích thước và phân mảnh củaMTU


Việc đóng gói một gói này bên trong một gói khác có thể dẫn đến một gói mới dài hơn kích thước
MTU của liên kết mà gói mới này phải được chuyển tiếp. Gói RFC 1702 [3] hoặc RFC 3147 [4]
mới nàycần phải không phải bị loại bỏ, do đó các gói này cần phải không phải đặt bit Don't
Fragment nếu chúng là các gói IPv4 và cần phải có cờ Phân đoạn Cho phép được đặt nếu chúng là
các gói CLNS.
Các gói đóng gói kết quả cần phải sau đó được phân mảnh trước khi được chuyển tiếp nếu gói tin
bây giờ dài hơn giới hạn MTU của liên kết.
Không cần thiết phải phân mảnh một gói trước khi đóng gói nó, vì gói đóng gói kết quả sẽ bị phân
mảnh nếu cần thiết.

B6.5.5 Yêu cầu đối với các nút kép hoặc đa ngôn ngữ có giao diện phát sóng (LAN)

B6.5.5.1 Quy trình bầu chọn nút Psuedo


Theo G.7712 [7], các nút chỉ IP không được phép tạo thành một kề với các nút chỉ OSI và các nút
chỉ IPv4 không được phép tạo một kề với các nút chỉ IPv6.
Do đó, khi các nút chỉ IP và chỉ dành cho OSI được kết nối với cùng một mạng LAN và trong cùng
một khu vực cấp 1 hoặc miền phụ cấp 2, thì các nút chỉ IP sẽ tạo thành các vùng liền kề với nhau và
sẽ chọn một điện cực giả trong khi OSI -chỉ có các nút sẽ tạo thành các nhánh bổ sung riêng biệt và
cũng có thể chọn một giả điện tử khác. Do đó, có thể có hai giả điện tử riêng biệt trên mạng LAN,
một cho các nút hỗ trợ OSI và một cho các nút hỗ trợ IP.
Điều tương tự có thể xảy ra nếu các nút chỉ IPv4 và chỉ IPv6 được kết nối với cùng một mạng LAN.
Một nút kép hoặc đa ngôn ngữ cần phảido đó, tham gia vào các quá trình bầu cử giả điện tử riêng
biệt này một cách độc lập cho từng lớp mạng mà nó hỗ trợ. Một nút đa ngôn ngữ cấp 1 / cấp 2cần
phải tham gia vào hai quy trình bầu cử giả điện tử cho mỗi giao thức lớp mạng mà nó hỗ trợ (một
cho mức 1 và một cho mức 2).
Mỗi pseudonode trên mạng LAN nằm trên một nút của giao thức lớp mạng tương thích với nút đa
ngôn ngữ sẽ có một phần kề với nút đa ngôn ngữ. Vì vậy, trên mạng LAN IP & OSI, nút kép chính
xác sẽ là nút có các bổ trợ hợp lệ cả với IP pseudonode và với pseudonode OSI (nếu có nhiều
pseudonode trên mạng LAN). Nút kép sẽ có cạnh kề với giả điện tử IP và với giả điện tử OSI,
nhưng giả điện tử IP sẽ không có cạnh kề trực tiếp với giả điện tử OSI và ngược lại, thay vào đó sẽ
chỉ đạt được kết nối thông qua nút kép.
Một nút kép có thể được chọn làm Bộ định tuyến được chỉ định bởi các nút hỗ trợ IP trên mạng
LAN, nhưng không phải bởi các nút hỗ trợ OSI; trong trường hợp này là nút képcần phải tạo một
pseudonode, nhưng pseudonode cần phải chỉ khai báo các điều khoản trong LSP của nó với các nút
hỗ trợ IP trên mạng LAN.
Tương tự, một nút kép có thể được chọn làm Bộ định tuyến được chỉ định bởi các nút hỗ trợ OSI
trên mạng LAN, nhưng không phải bởi các nút hỗ trợ IP; trong trường hợp này là nút képcần phải
tạo một pseudonode, nhưng pseudonode cần phải chỉ khai báo các adjacencies trong LSPS của nó
với các nút hỗ trợ OSI trên mạng LAN.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
52

Một nút kép có thể được chọn làm Bộ định tuyến được chỉ định bởi cả nút hỗ trợ IP và nút hỗ trợ
OSI trên mạng LAN; trong trường hợp này là nút képcần phải tạo một pseudonode để khai báo các
adjacencies trong LSP của nó cho tất cả các nút trên mạng LAN.
Về bản chất, một nút kép hoặc đa ngôn ngữ tham gia vào một quy trình bầu cử riêng biệt cho từng
giao thức lớp mạng mà nó hỗ trợ và nếu nó giành chiến thắng trong bất kỳ cuộc bầu cử nào thì nó sẽ
tạo ra một nút giả, nhưng nút giả sẽ khai báo các phần bổ trợ trong LSP của nó chỉ với tập hợp hoặc
tập hợp các nút đã chọn nó.
Do đó, các nút chỉ dành cho OSI hoặc chỉ IP có thể nhận các LSP từ một bộ giả có liệt kê các vùng
lân cận đến các nút trên mạng LAN mà chúng không thể nhìn thấy. Nếu một gói cần được chuyển
tiếp qua một nút như vậy thì nó NÊN được gửi đến IS được chỉ định theo ISO / IEC 10589 phần
C.2.5 mục “h” và theo RFC 1195 [1] phần C.1.4 bước 0 Điều 8 trên trang 73. Lưu ý rằng các điều
khoản này trong ISO / IEC 10589 và RFC 1195 là không quy chuẩn. Có thể có những triển khai
không thể hiện hành vi này. Việc triển khai như vậy sẽ làm rơi các gói thay vì gửi lưu lượng đến
một nút kép để đóng gói tự động, nếu nút kép là Bộ định tuyến được chỉ định và nếu các nút không
tương thích trên cùng một mạng LAN nằm trên đường ngắn nhất.
Do đó, người thực hiện và người vận hành có sự lựa chọn để thực hiện, sự lựa chọn là: -
1. Đặt mức độ ưu tiên của các nút kép hoặc đa ngôn ngữ thành giá trị cao. Điều này dẫn đến
một giả điện tử xuất hiện trên mạng LAN, được hỗ trợ bởi một nút kép hoặc đa ngôn ngữ.
Nhược điểm của cách tiếp cận này là có một cơ hội nhỏ là việc triển khai kế thừa tồn tại trên
mạng LAN không chuyển tiếp lưu lượng đến một nút kép nếu một nút không tương thích
trên mạng LAN nằm trên đường ngắn nhất.
Hoặc
2. Đặt mức độ ưu tiên của các nút kép hoặc đa ngôn ngữ thành giá trị thấp. Điều này dẫn đến
một pseudonode xuất hiện trên mạng LAN cho mọi giao thức tầng mạng được hỗ trợ, gửi
lưu lượng truy cập cho các nút không tương thích một cách rõ ràng thông qua một nút kép
hoặc đa ngôn ngữ. Điều này cải thiện khả năng tương tác nhưng tăng gấp đôi lượng LSP
được truyền vào mạng LAN, làm giảm khả năng mở rộng.
Khuyến nghị rằng mức độ ưu tiên của các nút kép và đa ngôn ngữ là có thể định cấu hình toán tử.

Quá trình cập nhật B6.5.5.2LSP


ISO / IEC 10589 [2] nêu rõ trong phần 7.3.15.1 rằng LSP nhận được không phải từ một cạnh hợp lệ
phải bị loại bỏ. Do đó, việc triển khai nghiêm ngặt chỉ dành cho OSI sẽ từ chối các LSP được truyền
vào giao diện LAN bởi một nút chỉ IP, vì nút chỉ IP đã từ chối sự kề cận theo G.7712 [7]. Do đó,
nút chỉ dành cho OSI chỉ có thể nhận một LSP như vậy từ một nút kép. Nếu không có hành vi sửa
đổi, nút kép sẽ chỉ chuyển tiếp một LSP như vậy trong quá trình đồng bộ hóa cơ sở dữ liệu LSP
định kỳ.
Do đó, các nút kép hoặc đa ngôn ngữ tuân theo tài liệu này được yêu cầu phải có hành vi tràn ngập
LSP được sửa đổi để các nút chỉ dành cho OSI hoặc chỉ IP không cần phải đợi sự kiện đồng bộ hóa
cơ sở dữ liệu LSP tiếp theo.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
53

Các nút kép hoặc đa ngôn ngữ tuân theo tài liệu này cần phảikiểm tra các LSP đến trên các giao
diện LAN để xem liệu chúng có đến từ một hàng xóm hỗ trợ tất cả các giao thức lớp mạng mà nút
kép hoặc nút đa ngôn ngữ thực hiện hay không. Cái nàycần phải đạt được bằng cách kiểm tra “các
giao thức được hỗ trợ” TLV trong gói Hello nhận được từ người hàng xóm đó.
Nếu LSP được nhận từ một hàng xóm hỗ trợ tất cả các giao thức lớp mạng mà nút kép hoặc nút đa
ngôn ngữ hỗ trợ, thì nút kép hoặc đa ngôn ngữ sẽ hoạt động theo ISO / IEC 10589 và bỏ đặt cờ
SRM cho LSP đó trên mạng LAN đó nếu nó đã có LSP, hoặc sẽ tràn nó ra khỏi tất cả các giao diện
khác nếu nó chưa có LSP.
Nếu LSP được nhận từ một hàng xóm không hỗ trợ tất cả các giao thức lớp mạng mà nút kép hoặc
nút đa ngôn ngữ hỗ trợ, và nếu nó chưa có LSP thì nút kép hoặc đa ngôn ngữ sẽ đặt cờ SRM cho
LSP đó trên giao diện LAN mà LSP đã được nhận, ngoài tất cả các giao diện khác, dẫn đến việc nút
kép hoặc đa ngôn ngữ truyền lại LSP vào mạng LAN.
Theo cách này nếu một LSP được truyền vào mạng LAN bởi một nút chỉ IP, thì một trong các nút
kép hoặc đa ngôn ngữ sẽ truyền lại LSP, để nó có thể được các nút chỉ dành cho OSI trên LAN và
ngược lại.

B6.5.5.3 Chuyển hướng


Nếu một bộ định tuyến kép bắt nguồn một yêu cầu chuyển hướng ICMP, yêu cầu cần phảikhông
chuyển hướng các gói IP từ một nút hỗ trợ IP đến một nút không hỗ trợ IP. Tương tự như vậy nếu
một bộ định tuyến kép bắt nguồn ISO / IEC 9542 [5] Chuyển hướng PDU, chuyển hướngcần phải
không chuyển hướng các gói CLNS từ một nút hỗ trợ OSI đến một nút không hỗ trợ OSI.

B6.5.5.4 Chỉ kết hợp RFC 1195 và tự động đóng gói các nút trên mạng LAN
Một nút kép tuân theo RFC 1195 [1] nhưng không tuân theo tài liệu này cần phải không phải nằm
trên một mạng LAN trong cùng một khu vực cấp 1 hoặc tên miền phụ cấp 2 với cả các nút chỉ IP và
chỉ OSI, vì nó có thể chuyển tiếp lưu lượng IP tới một nút chỉ OSI hoặc lưu lượng CLNS tới một
nút chỉ IP, dẫn đến mất gói.
Một nút kép tuân theo RFC 1195 [1] nhưng không tuân theo tài liệu này có thể nằm trên một mạng
LAN trong cùng một khu vực cấp 1 hoặc miền phụ cấp 2 như một nút kép hỗ trợ Chức năng làm
việc liên kết này.
Ngoài ra nó có thể nằm trên mạng LAN với nút chỉ OSI nếu nó chỉ có thể chuyển tiếp lưu lượng
CLNS tới nút đó, nút chỉ IPv4 nếu nó chỉ có thể chuyển tiếp lưu lượng IPv4 tới nút đó hoặc nút chỉ
IPv6 nếu chỉ có thể chuyển tiếp lưu lượng IPv6 tới nút đó.

B6.6 Yêu cầu đối với các nút ngăn xếp phân chia
Một nút ngăn xếp phân tách khởi tạo và kết thúc các gói thuộc loại giao thức tầng mạng mà nó
không thể chuyển tiếp nguyên bản trong các kênh DCC của nó. Do đó, cách duy nhất mà một nút
như vậy có thể khởi tạo hoặc kết thúc các gói như vậy là nếu chúng ở dạng đóng gói.
Giải pháp này đặc biệt hữu ích để thêm thẻ IP vào nút OSI chủ yếu hoặc nút sẽ được cài đặt vào
mạng OSI hiện có, chẳng hạn. Cũng có thể dễ dàng hơn khi nâng cấp một cổng OSI NE thành một
nút ngăn xếp phân tách, thay vì thành một nút kép, để lưu lượng IP có thể vào và ra khỏi mạng mà
nút đó là cổng kết nối.
Nút ngăn xếp chia tách cần phải có thể định tuyến nội bộ bất kỳ gói nào mà nó nhận được thuộc
giao thức tầng mạng bằng một trong những gói được liệt kê trong “giao thức hỗ trợ” TLV của IS-IS
LSP của nó.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
54

Một nút ngăn xếp phân chia cần phải sử dụng “giao thức được hỗ trợ” TLV trong IS-IS Hello PDU
để chỉ các giao thức lớp mạng mà nó có thể nhận và chuyển tiếp nguyên bản trên bất kỳ giao diện
riêng lẻ nào (hoặc không hỗ trợ TLV này nếu đó là giao diện chỉ dành cho OSI).
tức là một nút IP-over-OSI có thể định tuyến CLNS nguyên bản trong các kênh DCC của nó và có
thể định tuyến lưu lượng IP đến cho nó trong các đường hầm IP-over-OSI RFC 3147 hoặc có thể là
một giao diện Ethernet.
Do đó, một nút ngăn xếp phân tách có thể chỉ ra một giao thức lớp mạng trong TLV “các giao thức
được hỗ trợ” của gói Hello trên một giao diện và một giao thức lớp mạng khác trong TLV “các giao
thức được hỗ trợ” của gói Hello trên một giao diện khác. Một nút như vậy sẽ có thể định tuyến nội
bộ cả hai giao thức lớp mạng và như vậy sẽ quảng cáo cả hai trong TLV “các giao thức được hỗ
trợ” của các LSP của nó.
Một nút ngăn xếp phân chia cần phải sử dụng các TLV có khả năng tiếp cận IP trong IS-IS LSP để
chỉ ra phạm vi địa chỉ của các gói được đóng gói mà nó có thể kết thúc.
Một nút ngăn xếp phân tách có thể nhận được các tiện ích mở rộng khả năng truy cập IP từ một nút
chỉ IP, thông qua một nút kép hoặc đa ngôn ngữ. Do đó, nút ngăn xếp chia táchcần phảicó thể gửi
lưu lượng truy cập đến đích thông qua một nút kép, nút này sẽ sử dụng để đóng gói các gói tin của
nó. Để đạt được điều này, một nút ngăn xếp chia nhỏcần phải tìm kiếm nút tiếp theo dọc theo đường
dẫn đến từng đích có khả năng không đóng gói hoặc tìm điểm đến ngăn xếp phân tách, theo cách
giống hệt như cách mà một nút kép thực hiện.
Khi một nút ngăn xếp phân tách nhận được một gói tin được định sẵn cho chính nó, nó cần
phảikiểm tra gói tin đó để chắc chắn liệu nó có gói tin khác được đóng gói bên trong hay không.
Nếu vậy thì gói tin sẽ được xử lý nội bộ, trừ khi nó là gói IS-IS hoặc ES-IS trong trường hợp đócần
phải bị loại bỏ (trừ khi tồn tại một đường hầm được cấp phép thủ công với IS-IS được cấp phép để
chạy qua nó) theo cách tương tự như đối với một nút kép.
Theo cách tương tự như nút kép hoặc nút đa ngôn ngữ, nút ngăn xếp phân tách cần phải hỗ trợ đóng
gói RFC 1702 [3] hoặc RFC 3147 [4].

B6.7 Sử dụng Các nút IS-IS tích hợp trong các khu vực hỗn hợp không phù hợp với tài liệu này
Các nút phù hợp với RFC 1195 [1] nhưng không phù hợp với tài liệu này có thể được sử dụng trong
các khu vực hỗn hợp cấp 1 hoặc miền phụ cấp 2 một cách cẩn thận với các hạn chế dưới đây: -
Các nút IS-IS tích hợp chỉ hỗ trợ một giao thức lớp mạng nhưng không phù hợp với tài liệu này có
thể vẫn được sử dụng trong khu vực cấp 1 hoặc miền phụ cấp 2, nhưng trình quản lý mạng cần phải
đảm bảo theo cách thủ công rằng một nút như vậy không có bất kỳ chỗ dựa nào với các nút khác có
thể chuyển tiếp các gói đến nó mà nó không hỗ trợ.
Các nút IS-IS tích hợp (hoặc các cụm nút) hỗ trợ nhiều hơn một giao thức lớp mạng nhưng có chứa
tính năng được mô tả trong tài liệu này vẫn phải tuân theo các hạn chế cấu trúc liên kết của RFC
1195. Điều này có nghĩa là trình quản lý mạng cần phải đảm bảo rằng một nút như vậy không thể
chuyển các gói đến một nút lân cận không thể chuyển tiếp loại gói đó.
tức là kép (nc) biểu thị một nút IS-IS tích hợp kép phù hợp với RFC 1195 [1], nhưng điều đó không
phù hợp với tài liệu này
OSI ---- kép ---- kép (nc) ---- kép ---- IP là sự kết hợp an toàn
OSI ---- kép ---- kép (nc) ---- kép (nc) ---- kép (nc) ---- kép ---- IP là sự kết hợp an toàn
IPv4 ---- kép ---- kép (nc) ---- kép ---- IPv6 là sự kết hợp an toàn
Kép (nc) ---- kép ---- OSI ---- kép ---- kép (nc) là sự kết hợp an toàn

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
55

OSI --- IPv4 & OSI --- IPv4 & OSI (nc) --- IPv4 & IPv6 (nc) --- IPv4 & IPv6 --- IPv6 không phải là
sự kết hợp an toàn
OSI - IPv4 & OSI - IPv4 & OSI (nc) - IPv4 & IPv6 & OSI - IPv4 & IPv6 (nc) - IPv4 & IPv6 - IPv6
là sự kết hợp an toàn

B6.8 Yêu cầu đối với các nút cấp 1, cấp 2


Chúng tôi khuyến nghị rằng các nút hỗ trợ cả định tuyến mức 1 và mức 2 và có mặt trong vùng cấp
1 hoặc tên miền phụ cấp 2 trong đó Chức năng làm việc liên kết này được sử dụng: -
Hỗ trợ tất cả các giao thức lớp mạng có trong cả miền phụ cấp 1 và cấp 2 mà nút tham gia và hỗ
trợ các tính năng được mô tả trong tài liệu này.
hoặc
Hỗ trợ tất cả các giao thức lớp mạng có mặt trong cả miền phụ cấp 1 và cấp 2 mà trong đó nút
tham gia và được kết nối trực tiếp hoặc được kết nối thông qua các chuỗi liên tục của các nút
khác hỗ trợ tất cả các giao thức lớp mạng trong khu vực, đến một nút hỗ trợ tính năng này và hỗ
trợ tất cả các giao thức lớp mạng trong khu vực.
tức là (nc) biểu thị một nút IS-IS tích hợp phù hợp với RFC 1195 [1], nhưng điều đó không phù hợp
với tài liệu này: -
L2_ subdomain ---- dualL1 / L2 ---- any_node là an toàn
L2_ subdomain ---- dualL1 / L2 (nc) ---- dual --- any_node là an toàn
L2_ subdomain ---- dualL1 / L2 (nc) ---- dual (nc) ---- dual --- any_node là an toàn
L2_domain ---- dualL1 / L2 (nc) ---- non-dual là không an toàn (trừ khi áp dụng các hạn chế RFC
1195 [1])

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
56

Tuy nhiên, người ta hiểu rằng một cổng, và do đó một bộ định tuyến L1, L2, có thể là một thiết bị
chỉ dành cho OSI hiện có. Trong trường hợp này, có thể có IP và tự động đóng gói trong khu vực
bằng cách sử dụng phương pháp sau, cẩn thận: -

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
57

Một hoặc nhiều nút kép trong khu vực có thể được chọn làm cổng cho các gói IP. Các nút này sẽ
được cấu hình để quảng cáo một tuyến đường mặc định (0.0.0.0) vào khu vực để thu hút tất cả lưu
lượng IP “ngoài khu vực” đến chúng. Sau đó, các nút này sẽ chuyển tiếp tất cả lưu lượng “ngoài
khu vực” qua đường hầm RFC 3147 được cung cấp thủ công, đi qua nút chỉ dành cho OSI cấp 1,
cấp 2 đến một nút kép khác bên ngoài khu vực.
Nút kép nằm ngoài khu vực phải có tiền tố được cung cấp thủ công vào đó để thu hút tất cả lưu
lượng IP bị ràng buộc cho khu vực tới nó và gửi nó qua đường hầm vào khu vực đó. Theo tùy chọn,
một cơ chế, chẳng hạn như giao thức định tuyến IP có thể được cung cấp trên đường hầm để mỗi
đầu có thể xem liệu đầu kia còn sống hay không; tuy nhiên nếu IS-IS Tích hợp được sử dụng thì nó
phải là một phiên bản định tuyến khác với phiên bản được sử dụng chung trong khu vực, vì nó thực
sự là một miền định tuyến khác.
Nếu cơ chế như vậy được sử dụng thì nếu đầu xa biến mất, nút kép bên trong khu vực sẽ ngừng
quảng cáo một tuyến đường mặc định và nút kép bên ngoài khu vực sẽ ngừng quảng cáo tiền tố đại
diện cho các nút trong khu vực. Bằng cách này, các cổng IP dự phòng có thể được cung cấp.
Lưu ý rằng RFC1195 [1] nói rằng các tuyến mặc định không được quảng cáo trong các LSP cấp 1.
Giải pháp này yêu cầu phá vỡ quy tắc này. Thông thường nút RFC 1195 cấp 1 sẽ coi nút cấp 1, cấp
2 là tuyến mặc định của nó. Giải pháp này yêu cầu hành vi này phải được ghi đè bằng cách nhận
quảng cáo tuyến đường mặc định trong LSP cấp 1. Nếu điều này là không thể thì một công việc
xung quanh là để các nút cổng IP được định cấu hình với lựa chọn các tuyến tĩnh bao gồm tất cả các
điểm đến “ngoài khu vực” có thể có mà một ngăn xếp IP trong khu vực có thể cố gắng tiếp cận.

B6.9 Yêu cầu đối với miền phụ cấp 2


Có thể chấp nhận định tuyến tất cả các giao thức có mặt nguyên bản trong miền phụ cấp 2, theo
RFC 1195 [1], trong trường hợp đó không có nút cấp 2 nào cần hỗ trợ Chức năng InterWorking
này, nhưng tất cả chúng phải hỗ trợ tất cả giao thức lớp mạng hiện tại.
Ngoài ra, có thể chấp nhận sử dụng các nút cấp 2 hỗ trợ ít hơn tất cả các giao thức lớp mạng có
trong miền, trong trường hợp đó, các nút kép hoặc đa ngôn ngữ cấp 2 sẽ được yêu cầu để hỗ trợ
Chức năng InterWorking này để các gói có thể tự động được đóng gói để đi qua các nút như vậy.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
58

PHỤ LỤC I

Các hạn chế của các chức năng liên kết trong DCN

(Phụ lục này không phải là một phần không thể tách rời của Khuyến nghị này)

IntISIS R P OSPFM
Y
IP IntISIS
Dual IP IP K
NE
OSI/IP NE NE
IP
NE T
NE IP
G C Q N
OSI NE Dual
OSI S
NE IP IP IP IP OSI/IP
NE IP
NE NE NE NE NE
NE L
Z
IP V
F
Dual NE OSI
Dual
OSI/IP Dual NE
OSI Dual OSI/IP
OSI NE OSI/IP OSI 6
NE B OSI/IP Dual NE
NE NE X Dual NE
1 NE OSI/IP
W OSI/IP OSI
NE
NE NE
OSI IntISIS OSI
NE OSI
A NE IntISIS OSI NE
E
NE
S5 OSI OSI 3
OSI OSI
S6 IP NE NE
NE OSI
4 OSI
NE OSI
2 NE
NE
5

S2 IP
S3 OSI
S4 IP
IntISIS - Integrated ISIS S1 OSI

HÌNH I-1
Các tình huống liên kết

Giả thuyết chung:


DCN bao phủ IWF cho lớp 2-3 của các ngăn xếp IP-OSI. Các cơ chế liên kết áp dụng cho các lớp
khác nằm ngoài phạm vi của khuyến nghị này (tức là dàn xếp).
-Xem phần 7.1.7 để biết định nghĩa về liên kết.
Đường hầm dựa trên RFC.
NE hỗ trợ định tuyến IP chỉ dành cho IP và có thể chứa sự phân phối lại giữa ISIS và OSPF tích
hợp

Chung cho tất cả các tình huống:


Định tuyến động được thực hiện thông qua việc sử dụng phân phối lại tuyến của thông tin địa chỉ IP
giữa OSPF và ISIS NE. Phân phối lại tuyến đường được định dạng trước trên các nút OSPF giữa
các cặp; (R, P), (S, C), (M, K), (N, L).

Tình huống 1: Hệ thống quản lý dựa trên OSI được kết nối với nút A:
Phải có ít nhất một đường hầm được định cấu hình từ B đến một hoặc nhiều Y hoặc Z.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
59

Phải có một đường hầm được định cấu hình từ B đến X.


Phải có một đường hầm được định cấu hình từ B đến F
Phải có ít nhất một đường hầm được định cấu hình từ B đến một hoặc nhiều W, V hoặc T.
Các đường hầm trên có thể sẽ có IS-IS chạy ngang qua chúng (bên trong đường hầm), tuy nhiên các
kỹ thuật định tuyến liên miền cũng có thể xảy ra. Trong một số điều kiện, một số đường hầm có thể
bị tắc nghẽn do các lựa chọn định tuyến.
Hệ thống quản lý dựa trên OSI hiện có kết nối CLNS với bất kỳ NE chỉ dành cho OSI hoặc kép nào
trong mạng, nhưng không có kết nối với NE chỉ IP. Mặc dù một trình quản lý dựa trên OSI sẽ có
thể gửi các gói CLNS đến một NE ngăn xếp kép, nó sẽ không thể quản lý nó trừ khi có thể quản lý
được OSI.

Tình huống 2: Hệ thống quản lý dựa trên IP được kết nối với nút B.
Trong mạng cụ thể này, lưu lượng IP có thể được chuyển tiếp từ B tới tất cả các IP NE mà không
yêu cầu đường hầm. OSPF NEs P, C, M và N phải hỗ trợ phân phối lại các tuyến IP vào IS-IS tích
hợp. Các bộ lọc sẽ phải được cấu hình trên các nút OSPF P, C, M và N để ngăn các vòng lặp định
tuyến hình thành.
Hệ thống quản lý dựa trên IP hiện có kết nối IP với bất kỳ NE chỉ IP hoặc dual stack nào trong
mạng, nhưng không có kết nối với NE chỉ dành cho OSI. Mặc dù một trình quản lý dựa trên IP sẽ
có thể gửi các gói IP đến một NE ngăn xếp kép, nó sẽ không thể quản lý nó trừ khi có thể quản lý
IP.

Tình huống 3: Hệ thống quản lý dựa trên OSI được kết nối với nút C.
NE C không thể cung cấp kết nối OSI và do đó các gói CLNS không thể được chuyển tiếp, do đó hệ
thống quản lý dựa trên OSI không thể hoạt động tại vị trí này.

Tình huống 4: Hệ thống quản lý dựa trên IP được kết nối với nút E.
NE E không thể cung cấp kết nối IP và do đó các gói IP không thể được chuyển tiếp, do đó hệ
thống quản lý dựa trên IP không thể hoạt động tại vị trí này.

Tình huống 5: Hệ thống quản lý dựa trên OSI được kết nối với nút F.
Lưu lượng CLNS có thể đi qua NE F đến mạng OSI 2 mà không yêu cầu đường hầm vì NE F có thể
chuyển tiếp các gói CLNS nguyên bản.
Phải có một đường hầm được cấu hình từ F đến B.
Phải có ít nhất một đường hầm được định cấu hình từ F đến một hoặc nhiều Z hoặc Y.
Phải có một đường hầm được định cấu hình từ F đến X.
Phải có ít nhất một đường hầm được định cấu hình từ F đến một hoặc nhiều W, V hoặc T.
Các đường hầm trên có thể sẽ có IS-IS chạy ngang qua chúng (bên trong đường hầm), tuy nhiên các
kỹ thuật định tuyến liên miền cũng có thể xảy ra. Trong một số điều kiện, một số đường hầm có thể
bị tắc nghẽn do các lựa chọn định tuyến.
Hệ thống quản lý dựa trên OSI hiện có kết nối CLNS với bất kỳ NE chỉ dành cho OSI hoặc kép nào
trong mạng, nhưng không có kết nối với NE chỉ IP. Mặc dù một trình quản lý dựa trên OSI sẽ có

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
60

thể gửi các gói CLNS đến một NE ngăn xếp kép, nó sẽ không thể quản lý nó trừ khi có thể quản lý
được OSI.

Tình huống 6: Hệ thống quản lý dựa trên IP được kết nối với nút G.
Trong mạng cụ thể này, lưu lượng IP có thể được chuyển tiếp từ G tới tất cả các IP NE mà không
yêu cầu đường hầm. OSPF NEs P, C, M và N phải hỗ trợ phân phối lại các tuyến IP vào IS-IS tích
hợp. Các bộ lọc sẽ phải được định cấu hình trên mỗi nút OSPF P, C, M và N để ngăn các vòng lặp
định tuyến hình thành.
Hệ thống quản lý dựa trên IP hiện có kết nối IP với bất kỳ NE chỉ IP hoặc dual stack nào trong
mạng, nhưng không có kết nối với NE chỉ dành cho OSI. Mặc dù một trình quản lý dựa trên IP sẽ
có thể gửi các gói IP đến một NE ngăn xếp kép, nó sẽ không thể quản lý nó trừ khi có thể quản lý
IP.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
61

PHỤ LỤC II

VÍ DỤ VỀ TRIỂN KHAI ĐÓNG GÓI TỰ ĐỘNG


1. Giới thiệu
Phụ lục này không phải là một yêu cầu nhưng cung cấp các chi tiết ví dụ ngắn gọn về cách một nút
có thể được triển khai liên quan đến một khía cạnh của tính năng được chỉ định trong tài liệu này.

Cách đơn giản nhất (nhưng không phải là cách duy nhất) để một nút tính toán nút tiếp theo dọc theo
đường ngắn nhất đến đích cuối cùng của gói có thể mở gói là sửa đổi thuật toán SPF để đạt được
điều này.

Thuật toán có thể được sửa đổi để tìm nút tiếp theo dọc theo đường ngắn nhất đến đích có thể chấp
nhận IP qua lưu lượng truy cập được đóng gói OSI và nút tiếp theo dọc theo đường ngắn nhất đến
đích có thể chấp nhận lưu lượng truy cập được đóng gói OSI qua IP. Lưu ý rằng hai nút này có thể
là cùng một nút, hoặc có thể là hai nút riêng biệt. Thuật toán Dijkstra được sửa đổi được cung cấp
bên dưới để đạt được điều này.

Quá trình bổ sung này chỉ cần xảy ra khi bước tiếp theo không hỗ trợ giao thức lớp mạng của loại
tương ứng với địa chỉ đích cho đường dẫn đó. Nếu bước tiếp theo hỗ trợ loại giao thức lớp mạng đó
(như được chỉ định trong TLV “giao thức được hỗ trợ” trong IS-IS Hello PDUs nhận được từ nút
đó) thì các gói đến đích đó có thể chỉ được chuyển tiếp nguyên bản và bị quên, và do đó không cần
thiết tìm kiếm một nút dọc theo đường dẫn có thể đóng gói.

Sau đó, thuật toán phải xác định địa chỉ IP cho nút không đóng gói tiếp theo này nếu đích của
đường dẫn là Hệ thống cuối OSI và sau đó phải xác định địa chỉ OSI cho nút không đóng gói tiếp
theo này nếu đích của PATH là địa chỉ IP.

Không tìm thấy địa chỉ IP cho nút không đóng gói tiếp theo này chỉ ra lỗi cấu hình trong nút đó
(không có địa chỉ IP); tùy chọn này có thể dẫn đến thông báo lỗi được gửi đến quản trị viên mạng.
Việc mất gói sẽ xảy ra nếu gói CLNS yêu cầu đường hầm đến nút đó qua IP, vì không có địa chỉ
đích IP thì việc đóng gói địa chỉ đích có thể không thực hiện được và thay vào đó gói sẽ bị loại bỏ.

Việc không tìm thấy nút có thể mở gói cho thấy lỗi thiết kế mạng, cụ thể hơn là lỗi không tuân thủ
các hạn chế cấu trúc liên kết được nêu trong tài liệu này. Điều này sẽ dẫn đến báo cáo lỗi "không
thể truy cập đích".

Đối với mỗi đích IP yêu cầu đóng gói để vượt qua bước tiếp theo, nút sau đó có thể đặt một điểm
đánh dấu trong bảng chuyển tiếp IP cho biết địa chỉ đích OSI phải được sử dụng để đóng gói tất cả
các gói IP dành cho địa chỉ đó.

Đối với mỗi đích OSI yêu cầu đóng gói để vượt qua bước tiếp theo, nút sau đó có thể đặt một điểm
đánh dấu trong bảng chuyển tiếp OSI cho biết địa chỉ đích IP phải được sử dụng để đóng gói tất cả
các gói OSI dành cho địa chỉ đó.

Một nút hỗ trợ IPv4, IPv6 và OSI có thể tìm thấy hai địa chỉ (ví dụ: địa chỉ IPv4 và địa chỉ IPv6) có
thể được sử dụng để đóng gói. Trong trường hợp này, nó có thể chọn miễn là nó dẫn đến một gói
thuộc loại giao thức lớp mạng mà bước tiếp theo hỗ trợ (như được chỉ định trong TLV “được hỗ trợ
giao thức” trong IS-IS Hello PDUs nhận được từ nút đó) .

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
62

2. Cập nhật cho Thuật toán Dijkstra


Phụ lục sau đây chứa đầy đủ thuật toán Dijkstra bao gồm các phần mở rộng để hỗ trợ tự động đào
hầm. Nó dựa trên thuật toán như được chỉ định trong RFC1195. Thuật toán được hiển thị phù hợp
với nút tự động đào hầm kép IPv4 và CLNS. Các thay đổi đối với thuật toán này được hiển thị
trongIn nghiêng đậm

Thuật toán tạo ra một cơ sở dữ liệu PATHS chứa cho mỗi điểm đến danh tính của nút đầu tiên từ S
đến N có khả năng không đóng gói IP qua OSI và danh tính của nút đầu tiên từ S đến N có khả năng
không đóng gói OSI qua IP.

Đối với mỗi đích IP, nút đầu tiên từ S đến N có khả năng không đóng gói IP qua OSI có thể có địa
chỉ OSI của nó được tải vào bảng chuyển tiếp IP làm địa chỉ đích được sử dụng trong bất kỳ gói
CLNP nào được sử dụng để đóng gói IP qua OSI, nếu tiếp theo hop không hỗ trợ IP.

Đối với mỗi Hệ thống cuối OSI, nút đầu tiên từ S đến N có khả năng không đóng gói OSI qua IP có
thể có một trong các địa chỉ IP của nó được tải vào bảng chuyển tiếp OSI làm địa chỉ đích được sử
dụng trong bất kỳ gói IP nào được sử dụng để đóng gói OSI qua IP, nếu bước tiếp theo không hỗ trợ
OSI.
2.1 Các thay đổi đối với Cơ sở dữ liệu
Cơ sở dữ liệu PATHS và TENTS phải được cập nhật để chứa phần mở rộng cho {Adj (N)}, phần tử
của bộ ba. Phần tử N liền kề sẽ chứa hai mục nhập Hỗ trợ giao thức kép (IDP (N) -ODP (N)) tương
ứng sẽ đại diện cho ID hệ thống của bộ định tuyến kép đầu tiên trên đường dẫn từ S đến N có khả
năng bỏ đóng gói IP qua đường hầm OSI gói (IDP (N)) và ID hệ thống của bộ định tuyến kép đầu
tiên trên đường dẫn từ S đến N đó có khả năng loại bỏ đóng gói OSI qua các gói có đường hầm IP
(ODP (N). Nếu không tồn tại bộ định tuyến * DP (N) trên PATH thì giá trị này sẽ được đặt thành 0.
Nếu tồn tại nhiều mục điều chỉnh (N) trong cơ sở dữ liệu TENTS hoặc PATHS thì mỗi cạnh kề sẽ
có các mục nhập * DP (N) tương ứng. Vì vậy, mỗi bộ ba sẽ có định dạng <N, d (N), {Adj (N) -IDP
(N) -ODP (N)}>
Nếu giá trị của IDP (N) được đặt thành 0 thì điều này có nghĩa là không có bộ định tuyến kép nào
tồn tại trên đường dẫn đến đích có khả năng khử đóng gói và đóng gói IP qua các gói OSI.
Nếu giá trị của ODP (N) được đặt thành 0 thì điều này có nghĩa là không có bộ định tuyến kép nào
tồn tại trên đường dẫn đến đích có khả năng khử đóng gói và đóng gói OSI qua các gói IP.
2,2 Các thay đổi đối với thuật toán
Thuật toán SPF được chỉ định trong phần C.2.3 của [1] được sửa đổi để xuất hiện như sau:

Bước 0: Khởi tạo TENT và PATHS để trống. Khởi tạo độ mạnh để


[internalmetric = 0, externalmetric = 0].

(độ mạnh là sức mạnh của các yếu tố trong TENT mà chúng ta đang
đang kiểm tra.)

1) Thêm <SELF, 0, W-0-0> thành PATHS, trong đó W là một giá trị đặc biệt cho biết
lưu lượng truy cập vào SELF được chuyển đến các quy trình nội bộ (thay vì
chuyển tiếp).

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
63

2) Bây giờ hãy tải trước TENT với cơ sở dữ liệu kề cục bộ (Mỗi
mục nhập được thực hiện cho TENT phải được đánh dấu là Hệ thống kết thúc
hoặc bộ định tuyến để cho phép thực hiện kiểm tra ở cuối Bước 2
chính xác - Lưu ý rằng mỗi mục nhập khả năng truy cập IP cục bộ là
được bao gồm như một phụ kiện liền kề và được đánh dấu là một Hệ thống Kết thúc).
Đối với mỗi lần tiếp theo Điều chỉnh (N) (bao gồm Hướng dẫn sử dụng OSI cấp 1
Các địa chỉ có thể truy cập được hỗ trợ OSI hoặc cấp độ 2, và
Các mục nhập khả năng truy cập IP) trên các mạch đã bật, đến hệ thống N của
SELF ở trạng thái "Lên" tính toán:

d (N) = chi phí của mạch mẹ của cạnh kề (N),


thu được từ metric.k, trong đó k = một trong {số liệu mặc định,
chỉ số độ trễ, số liệu tiền tệ, số liệu lỗi}

Điều chỉnh (N)-IDP (N) - ODP (N) = số kề của vùng kề với N ,


SID của bộ định tuyến bước tiếp theo dọc theo đường dẫn đến hàng xóm có khả năng
hủy đóng gói IP qua các gói OSI và SID của bộ định tuyến bước tiếp theo
dọc theo đường dẫn đến hàng xóm có khả năng khử đóng gói OSI qua các gói IP.
Trong trường hợp này, tức là trong quá trình khởi tạo, cả hai giá trị DP sẽ được đặt
thành 0

3) Nếu một bộ ba <N, x, {Adj (M)-IDP (N) -ODP (N)}> ở trong TENT, sau đó:

Nếu x = d (N) thì {Adj (M)-IDP (N) -ODP (N)} <--- {Adj (M)-IDP (M) -ODP (M)}
U {Adj (N)-IDP (N) -ODP (N)}.

4) Nếu N là một bộ định tuyến hoặc một mục nhập Hệ thống cuối OSI, và bây giờ có
nhiều adjacencies trong {Adj (M)} hơn MaximumPathSplits, sau đó loại bỏ
bổ sung vượt quá như được mô tả trong Khoản 7.2.7 của [1]. Nếu N
là một Mục nhập khả năng tiếp cận IP, khi đó, các phần bổ sung vượt quá có thể là
loại bỏ như mong muốn. Điều này sẽ không ảnh hưởng đến tính đúng đắn của
định tuyến, nhưng có thể loại bỏ yếu tố xác định đối với các tuyến IP (ví dụ:
Các gói IP vẫn đi theo các tuyến đường tối ưu trong một khu vực, nhưng
nơi tồn tại nhiều tuyến đường tốt như nhau, sẽ không nhất thiết

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
64

theo dõi chính xác tuyến đường mà bất kỳ một bộ định tuyến cụ thể nào
đã dự đoán trước).

5) Nếu x <d (N), không làm gì cả.

6) Nếu x> d (N), loại bỏ <N, x, {Adj (M)-IDP (M) -ODP (M)}> từ TENT và thêm bộ ba
<N, d (N), {Adj (N) -IDP (N) -ODP (N)}>.

7) Nếu không có bộ ba nào <N, x, {Adj (M) -IDP (M) -ODP (M) }> đang ở trong TENT, sau đó
thêm
<N, d (N), {Adj (N) -IDP (N) -ODP (N)}> đến TENT.

8) Bây giờ hãy thêm các hệ thống mà bộ định tuyến cục bộ không có bộ định tuyến,
nhưng được đề cập trong các LSP giả điện tử lân cận. Các
kề cho các hệ thống như vậy được đặt thành của bộ định tuyến được chỉ định.
Lưu ý rằng điều này không bao gồm các mục nhập khả năng truy cập IP từ
các LSP giả điện tử lân cận. Đặc biệt, các LSP giả điện tử
không bao gồm các mục nhập khả năng truy cập IP.

9) Đối với tất cả các mạch phát sóng ở trạng thái "Bật", hãy tìm điện trở giả
LSP cho mạch đó (cụ thể là LSP với số 0 và
với 7 octet đầu tiên của LSPID bằng LnCircuitID cho điều đó
mạch, trong đó n là 1 (đối với định tuyến cấp 1) hoặc 2 (cấp 2
định tuyến)). Nếu nó có mặt, tất cả những người hàng xóm N đã báo cáo trong
tất cả các LSP của pseudonode này không tồn tại trong TENT thêm
một mục nhập <N, d (N), {Adj (N) -IDP (N) -ODP (N)}> tới TENT, trong đó:

d (N) = metric.k của mạch.


Adj (N) = số lượng kề cận của DR.

10) Chuyển đến Bước 2.

Bước 1: Kiểm tra PDU trạng thái liên kết không của P, hệ thống chỉ
được đặt trên PATHS (tức là LSP có cùng 7 octet đầu tiên của LSPID
như P, và số LSP bằng không).

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
65

1) Nếu LSP này hiện diện và bit "Chi phí Hippity Vô hạn" là rõ ràng
Đối với mỗi cặp Adj (*) - IDP (*) - ODP (*) trong cơ sở dữ liệu PATHS cho P.
Nếu đây không phải là một LSP nút giả và nếu IDP (*) bằng 0 thì hãy kiểm tra
trường khả năng không đóng gói của LSP, nếu nó hỗ trợ IP qua OSI
sau đó đặt giá trị IDP (P) cho lần kề này là ID hệ thống của P.
nếu ODP (*) bằng 0 thì kiểm tra
trường khả năng không đóng gói của LSP, nếu nó hỗ trợ OSI qua IP
sau đó đặt giá trị IDP (P) cho lần kề này là ID hệ thống của P

2) Nếu LSP này hiện diện và bit "Chi phí Hippity Vô hạn" là
rõ ràng, sau đó cho mỗi LSP của P (nghĩa là, tất cả các LSP có cùng
7 octet đầu tiên của LSPID và P, bất kể giá trị của
Số LSP) tính toán:

dist (P, N) = d (P) + metric.k (P, N)

cho mỗi hàng xóm N (cả Hệ thống đầu cuối và bộ định tuyến) của hệ thống P. Nếu
bit "Chi phí Hippity Vô hạn" được đặt, chỉ xem xét Hệ thống cuối
láng giềng của hệ thống P.
Lưu ý rằng các hàng xóm của Hệ thống cuối của
hệ thống P bao gồm các mục nhập địa chỉ IP có thể truy cập được bao gồm trong các LSP
từ hệ thống P. Ở đây, d (P) là phần tử thứ hai của bộ ba

<P, d (P), {Adj (P)-IDP (P) -ODP (P)}>

và metric.k (P, N) là chi phí của liên kết từ P đến N như được báo cáo trong
P của trạng thái liên kết PDU.

3) Nếu dist (P, N)> MaxPathMetric, thì không làm gì cả.

4) Nếu <N, d (N), {Adj (N) - IDP (N) -ODP (N)}> nằm trong PATHS, sau đó không làm gì cả.

Lưu ý: d (N) phải nhỏ hơn dist (P, N), nếu không N sẽ không

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
66

đã được đưa vào PATHS. Một cuộc kiểm tra sự tỉnh táo bổ sung có thể được
được thực hiện ở đây để đảm bảo rằng d (N) trên thực tế nhỏ hơn dist (P, N)

6) Nếu một bộ ba <N, x, {Adj (N) -IDP (N) -ODP (N)}> ở trong TENT, sau đó:

a) Nếu x = dist (P, N) thì {Adj (N), IDP (N) -ODP (N)} <-
{Điều chỉnh (N) -IDP (N) -ODP (N)} U {Adj (P) -IDP (P) -ODP (N)}.
Lưu ý rằng ngay cả khi giá trị của Adj (N) bằng giá trị Adj (P)
nhưng các giá trị tương ứng của IDP (P) hoặc ODP (P) và IDP (N)
hoặc ODP (N) là khác nhau
thì điều này nên được coi là một vùng liền kề khác và sẽ đại diện cho
một con đường khác đến đích.

b) Nếu N là một bộ định tuyến hoặc một hệ thống cuối OSI và bây giờ có nhiều
adjacencies trong {Adj (N)} so với MaximumPath Splits, sau đó loại bỏ
bổ sung dư thừa, như được mô tả trong khoản 7.2.7 của [1]. Vì
Các mục nhập khả năng tiếp cận IP, các phần bổ sung vượt quá có thể bị xóa dưới dạng
mong muốn. Điều này sẽ không ảnh hưởng đến tính đúng đắn của định tuyến, nhưng
có thể loại bỏ tính xác định đối với các tuyến IP (tức là, các gói IP
sẽ vẫn đi theo các tuyến đường tối ưu trong một khu vực, nhưng ở đâu
nhiều tuyến đường tốt như nhau tồn tại, không nhất thiết sẽ tuân theo
chính xác tuyến đường mà bất kỳ một bộ định tuyến cụ thể nào sẽ có
dự đoán).

c) nếu x <dist (P, N), không làm gì cả.

d) nếu x> dist (P, N), loại bỏ <N, x, {Adj (N)- IDP (N) -ODP (N)}> từ TENT và thêm
<N, dist (P, N), {Adj (P)- IDP (P) -ODP (P)}>

7) nếu không có bộ ba nào <N, x, {Adj (N)}> trong TENT, thì hãy thêm
<N, dist (P, N), {Adj (P)}> thành TENT.

Bước 2: Nếu TENT trống, hãy dừng lại. Khác:

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
67

1) Tìm phần tử <P, x, {Adj (P)-IDP (P) -ODP (P)}>, với x tối thiểu như sau:

a) Nếu một phần tử <*, t Treatngth, *> vẫn còn trong TENT trong danh sách cho
sức mạnh, chọn phần tử đó. Nếu có nhiều hơn một
các phần tử trong danh sách cho độ mạnh, hãy chọn một trong các phần tử
(nếu có) đối với hệ thống là một điện cực giả được ưu tiên hơn một
cho một không phải pseudonode. Nếu không có phần tử nào nữa trong danh sách
đối với cường độ, cường độ gia tăng và lặp lại Bước 2.

b) Loại bỏ <P, t Bentley, {Adj (P)-IDP (P) -ODP (P)}> từ TENT.

c) Thêm <P, d (P), {Adj (P) -IDP (P) -ODP (P)}> tới PATHS.

d) Nếu đây là Quy trình Quyết định Cấp 2 đang chạy và hệ thống
vừa được thêm vào PATHS được liệt kê là Phân vùng được Chỉ định Cấp 2
Hệ thống trung gian, sau đó thêm <AREA.P, d (P), {Adj (P)}>
đến PATHS, trong đó AREA.P là Tiêu đề thực thể mạng của đối tượng kia
cuối của Liên kết ảo, có được bằng cách lấy VÙNG đầu tiên
được liệt kê trong LSP của P và thêm ID của P.

e) Nếu hệ thống vừa được thêm vào PATHS là hệ thống kết thúc, hãy chuyển đến
bước 2. Còn lại, hãy chuyển sang Bước 1.

LƯU Ý - Trong ngữ cảnh cấp 2, "Hệ thống cuối" là tập hợp của
Tiền tố địa chỉ có thể tiếp cận (cho OSI), tập hợp các địa chỉ khu vực với
chi phí bằng không (một lần nữa, đối với OSI), cộng với tập hợp các mục nhập khả năng truy cập
IP
(bao gồm cả bên trong và bên ngoài).

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
68

PHỤ LỤC III


Hướng dẫn khởi động cho các NE SDH trong Môi trường RFC 1195 Kép
và Tác động của tùy chọn đóng gói tự động

1. Giới thiệu
Phụ lục này cung cấp hướng dẫn về cách cài đặt các nút IS-IS tích hợp trong mạng IPv4 và OSI kép
cũng như cách sử dụng tính năng đóng gói tự động tùy chọn được mô tả trong Phụ lục B.

2. IS-IS tích hợp mà không cần đóng gói tự động


2.1 Giới thiệu và Quy tắc của RFC 1195
IS-IS tích hợp như được chỉ định trong RFC 1195 [1] ban đầu được viết như một giao thức định
tuyến kép. Cụ thể, nó được viết để có thể định tuyến cả IPv4 và CLNP bằng cách sử dụng một phép
tính SPF duy nhất, một bộ số liệu duy nhất cho cả IP và CLNP, và một bộ Hellos và LSP.
Cụ thể hơn, các bộ định tuyến IS-IS tích hợp tuân theo RFC 1195 [1] tính toán các đường dẫn ngắn
nhất qua vùng cấp 1 hoặc miền phụ cấp 2 mà không cần xem xét liệu bộ định tuyến ứng viên nào có
thể thực sự chuyển tiếp một loại gói tin cụ thể hay không.
Điều này được nêu rõ trong RFC 1195 [1] trong phần 3.10: -
"Tính toán Dijkstra không xem xét liệu một bộ định tuyến là chỉ IP, chỉ OSI
hay kép. Các giới hạn cấu trúc liên kết được chỉ định trong phần 1.4 đảm
bảo rằng các gói IP sẽ chỉ được gửi qua các bộ định tuyến hỗ trợ IP và các
gói OSI sẽ chỉ được gửi qua các bộ định tuyến hỗ trợ OSI. "

Với IS-IS tích hợp, một bộ định tuyến chỉ là một bộ định tuyến. Giả định là bất kỳ bộ định tuyến
nào trong mạng có thể xử lý bất kỳ loại gói nào được ném vào nó.
Do đó, các bộ định tuyến IS-IS tích hợp tính toán các tuyến đường và chuyển tiếp các gói tin dựa
trên giả định này và người vận hành có trách nhiệm đảm bảo rằng giả định này thực sự đúng.
Do đó, có các hạn chế tôpô của RFC 1195. Việc không thực thi các giới hạn tôpô của RFC 1195 có
thể dẫn đến mất gói, vì các gói biến mất vào lỗ đen của bộ định tuyến. Nó chỉ loại bỏ các gói mà nó
không thể chuyển tiếp, vì nó không hỗ trợ họ.
Trong một mạng khu vực cấp 1 đơn giản, các quy tắc khá đơn giản. Đó là:-
1.Nếu các gói IPv4 được chuyển tiếp trong một khu vực, thì tất cả các bộ định tuyến trong khu vực
đó phải có thể chuyển tiếp các gói IPv4.
2.Nếu các gói CLNP được chuyển tiếp trong một khu vực, thì tất cả các bộ định tuyến trong khu
vực đó phải có thể chuyển tiếp các gói CLNP.
3.Nếu cả hai gói IPv4 và CLNP được chuyển tiếp trong một khu vực, thì tất cả các bộ định tuyến
trong khu vực đó phải là loại kép, tức là có thể chuyển tiếp cả hai.
Do đó, khá dễ dàng để phân loại các khu vực IS-IS cấp-1 thành các lớp "khu vực chỉ dành cho
OSI", khu vực chỉ IP "và" Khu vực kép ".
Điều này được thể hiện trong hình 1.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
69

Area 0001 Area 0002 Area 0003


IP-only area Dual area OSI-only area

IP
IP Dual OSI OSI
NE Dual
NE NE NE
IP/OSI IP/OSI
NE NE
IP Dual
OSI Dual
NE IP/OSI Dual NE IP/OSI
NE IP/OSI NE
NE

Within this area all Within this area all Within this area all
nodes must be able to nodes must be able to nodes must be able to
forward IPv4. forward IPv4 and forward CLNP.
CLNP packets will be CLNP. IP packets will be
discarded. Nodes can be IP discarded.
Dual nodes are allowed managed or CLNS Dual nodes are allowed
but must be IP managed. but must be CLNS
managed. managed.
Hình 1
2,2 Tên miền phụ cấp 2
Nếu cần một mạng lớn hơn, yêu cầu định tuyến mức 2, thì miền con mức 2 sẽ chuyển tiếp các gói
giữa các vùng mức 1 và do đó phải hỗ trợ tất cả các loại gói có trong tất cả các vùng mức 1 đó. Các
quy tắc cho miền phụ cấp 2 là: -
1.Nếu các gói IPv4 được chuyển tiếp trong bất kỳ khu vực nào (khu vực chỉ IP hoặc Khu vực kép),
thì tất cả các bộ định tuyến trong miền phụ cấp 2 phải có thể chuyển tiếp IPv4.
2.Nếu các gói CLNP được chuyển tiếp trong bất kỳ khu vực nào (chỉ dành cho OSI hoặc Khu vực
kép), thì tất cả các bộ định tuyến trong miền phụ cấp 2 phải có thể chuyển tiếp CLNP.
Do đó, nếu bất kỳ khu vực nào là kép hoặc nếu cả hai khu vực chỉ OSI và chỉ IP đều tồn tại, thì các
bộ định tuyến trong miền phụ cấp 2 phải là vùng kép. Điều này được minh họa trong hình 2.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
70

L2 L2
L1,L2 L1,L2
Level-2 subdomain

Dual L1,L2 Dual


IP/OSI IP/OSI
Dual Dual
NE NE
IP/OSI IP/OSI
Dual Dual
NE NE
IP/OSI IP/OSI
NE NE

IP
IP Dual OSI OSI
NE Dual
NE NE NE
IP/OSI IP/OSI
NE NE
IP Dual
OSI Dual
NE IP/OSI Dual NE IP/OSI
NE IP/OSI NE
NE

Area 0001 Area 0002 Area 0003


IP-only area Dual area OSI-only area

As both IPv4 and CLNP are forwarded within the level-1 areas, all of the nodes in the
level-2 sub-domain must be dual, even those present in IP-only or OSI-only areas.
A node is in the level-2 sub-domain if it running level-2 routing.
Hình 2
2.3 Miền phụ cấp 2 có Bộ định tuyến bên ngoài chạy IS-IS tích hợp
Nhiều nhà khai thác hiện đang chạy định tuyến IS-IS cấp 1 trong các NE SDH chỉ dành cho OSI
của họ, sau đó liên kết nhiều khu vực bằng cách sử dụng định tuyến IS-IS cấp 2 trong mạng bộ định
tuyến bên ngoài.
Nếu nhà khai thác muốn sử dụng mô hình tương tự cho mạng kép thì họ có thể chạy IS-IS tích hợp
cấp 1 trong từng khu vực và IS-IS tích hợp cấp 2 trong mạng bộ định tuyến bên ngoài. Điều này tạo
ra một mạng rất giống với mạng trước đó, như thể hiện trong Hình 3

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
71

L2 L2
L1,L2 L1,L2
Level-2 subdomain

Dual L1,L2 Dual


IP/OSI IP/OSI
Dual Dual
router router
IP/OSI IP/OSI
Dual Dual
router router
IP/OSI IP/OSI
router router

IP
IP Dual OSI OSI
NE Dual
NE NE NE
IP/OSI IP/OSI
NE NE
IP Dual
OSI Dual
NE IP/OSI Dual NE IP/OSI
NE IP/OSI NE
NE

Area 0001 Area 0002 Area 0003


IP-only area Dual area OSI-only area

As both IPv4 and CLNP are forwarded within the level-1 areas, all of the routers in the
level-2 sub-domain must be dual, even those present in IP-only or OSI-only areas.
Hình 3
2,4 Bộ định tuyến bên ngoài chạy OSPF hoặc các giao thức định tuyến IP khác
Nhiều nhà khai thác hiện đang chạy IS-IS cấp 2 trong các bộ định tuyến bên ngoài của họ và OSPF
hoặc các giao thức định tuyến khác cho IP. Trong trường hợp này, bộ định tuyến bên ngoài phải vẫn
là bộ định tuyến cấp 2 cho các SDH NE và vì vậy đối với khu vực kép phải là bộ định tuyến IS-IS
tích hợp kép. Tuy nhiên, bộ định tuyến có thể được cấu hình để định tuyến tất cả các gói IP bằng
OSPF bằng cách định cấu hình phân phối lại các tuyến IP giữa IS-IS và OSPF. Theo cách này, tất
cả các gói IP sẽ được định tuyến OSPF, trong khi các gói CLNP tiếp tục được định tuyến IS-IS mức
2. Điều này được thể hiện trong hình 4.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
72

These routers must redistribute between OSPF


and Integrated IS-IS.
The default metric distributed into IS-IS must
be more attractive that the level-2 subdomain.

L2 L2
L1,L2 L1,L2

OSPF OSPF
IS-IS IS-IS
IP OSI
router router
router IS-IS
Dual Dual
IP/OSI router
IP/OSI
router router

IP
IP L1,L2 OSI OSI
NE Dual Dual
NE NE NE
IP/OSI IP/OSI
NE NE
IP Dual
OSI Dual
NE IP/OSI Dual NE IP/OSI
NE IP/OSI NE
NE

Area 0001 Area 0002 Area 0003


IP-only area Dual area OSI-only area

hinh 4
Lưu ý rằng ngăn xếp IS-IS tích hợp trong các bộ định tuyến bên ngoài sẽ không biết rằng miền phụ
cấp 2 chỉ dành cho các gói CLNP. Do đó, các tuyến đã học OSPF phải được phân phối lại thành IS-
IS tích hợp với số liệu mặc định thấp, để làm cho chúng hấp dẫn hơn đối với các gói IP so với miền
con cấp 2.
3. IS-IS tích hợp với tự động đóng gói
3.1 Giới thiệu và ảnh hưởng đến các hạn chế về cấu trúc liên kết
Tùy chọn đóng gói tự động cho phép phá vỡ các quy tắc cấu trúc liên kết của RFC 1195. Tự động
đóng gói một cách hiệu quả làm cho một nút hoặc một nhóm các nút dường như có thể chuyển tiếp
các gói mà chúng thực sự không thể.
Điều này được thể hiện trong hình 5.
AE AE
OSI OSI
A IP/OSI
NE NE
IP/OSI B
NE NE

AE = Automatically Encapsulating

Hình 5
Nhóm nút này bây giờ sẽ chuyển tiếp cả gói IPv4 và CLNP, miễn là các gói đi vào điểm A hoặc B,
thông qua một trong các nút đóng gói tự động.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
73

Giờ đây, nhóm nút có thể được đưa vào vùng kép hoặc miền phụ cấp 2 một cách an toàn, vì cặp nút
đóng gói tự động sẽ chuyển tiếp các gói IPv4 bằng cách đóng gói chúng bên trong các gói CLNP,
để chúng được chuyển tiếp bởi chỉ OSI NEs chứ không phải bị loại bỏ.
Một vùng kép hợp lệ bây giờ có thể trông giống như thể hiện trong hình 6.

Dual Dual
IP/OSI IP/OSI
NE NE

AE AE
IP/OSI OSI OSI
IP/OSI
NE NE NE
NE

AE Dual
IP/OSI IP/OSI
NE NE

Area 0004 OSI-only sub-network


Dual area
Only CLNP packets can be
forwarded in this part of the
AE = Automatically Encapsulating area.
IP packets will be encapsulated
into CLNP by AE nodes that
surround the sub-network
Hình 6
Lưu ý rằng các nút chỉ dành cho OSI không được kết nối trực tiếp với một trong các nút kép không
có tùy chọn đóng gói tự động. Chỉ sự hiện diện của các nút đóng gói tự động mới ngăn các gói IPv4
được gửi đến một nút chỉ dành cho OSI.
Một nút kép có thể được kết nối trực tiếp với một nút chỉ dành cho OSI nếu nó cũng được coi là
một nút chỉ dành cho OSI, như thể hiện trong hình 7.
AE Dual AE
OSI OSI
A IP/OSI
NE
IP/OSI
NE
IP/OSI B
NE NE NE

AE = Automatically Encapsulating

Hình 7
Trong trường hợp này mạng hoạt động như một mạng kép cho các gói đi từ điểm A đến B, nhưng
các gói IPv4 không thể đến được nút kép trung tâm. Nút kép này nằm bên trong mạng con chỉ dành
cho OSI. Nút kép này sẽ chỉ có thể chuyển tiếp các gói CLNP và phải được quản lý CLNS. Không
được có kết nối nào khác tới nút kép trung tâm, vì nếu gói IPv4 được đưa vào nút trung tâm, thì
chúng có thể được chuyển tiếp đến nút chỉ dành cho OSI và bị loại bỏ.
3.2 Nhận lưu lượng IP vào và ra khỏi mạng nhúng SDH
3.2.1 Cổng có khả năng IP NE

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
74

Cả gói IP và CLNP phải có thể đi vào và rời khỏi một vùng kép, cho dù có sử dụng tính năng đóng
gói tự động hay không. Thông thường, lưu lượng truy cập vào và ra khỏi khu vực IS-IS thông qua
các bộ định tuyến cấp 1, cấp 2. Đây là những bộ định tuyến tham gia vào cả khu vực cấp 1 và miền
phụ cấp 2.
Cách đơn giản nhất để xây dựng điều này là đảm bảo rằng mọi bộ định tuyến cấp 1, cấp 2 đều là bộ
định tuyến kép, như trong hình 8.

Level-2 subdomain

L2 link L1,L2 link L2 link

Dual Dual
IP/OSI IP/OSI
router router

AE AE
IP/OSI OSI OSI
IP/OSI
NE NE NE
NE

AE Dual
IP/OSI IP/OSI
NE NE

Area 0004
Dual area

AE = Automatically Encapsulating

Hình 8
3.2.2 OSI Cổng chỉ NE
Đôi khi, các nút tự động đóng gói sẽ được sử dụng để nâng cấp vùng chỉ dành cho OSI hiện có để
biến nó thành vùng kép một cách hiệu quả. Trong trường hợp này, các nút cổng có thể phải giữ
nguyên là các nút chỉ dành cho OSI. Trong trường hợp này, một mạng có thể được xây dựng như
trong hình 9.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
75

OSPF
Access DCN

OSPF & OSPF &


10.3.0.0/16 L1,L2 OSI L1,L2 OSI
router 10.3.0.0/16
router

Manual OSI OSI Manual


RFC 3147 gateway NE NE RFC 3147
NE
tunnel tunnel
OSI OSI OSI
OSI NE Static/default
Static/default NE NE
NE route not
route not advertised if
advertised if AE
tunnel fails
tunnel fails AE IP/OSI AE
0.0.0.0 IP/OSI NE IP/OSI 0.0.0.0
NE NE
IP
NE IP
NE
Level-1 area=10.3.x.x

Area 0005
Dual area
AE = Automatically Encapsulating

Hình 9
Trong mạng này, các gói CLNP cần rời khỏi khu vực mức 1 tiếp tục đi đến bộ định tuyến OSI mức
1, mức 2. Các nút có đường hầm thủ công dẫn ra khỏi khu vực cấp 1 quảng cáo đây là tuyến đường
mặc định. Do đó, tất cả các nút hỗ trợ IP sẽ thêm một mục vào cuối bảng định tuyến của chúng để
yêu cầu chúng gửi tất cả các gói IPv4 đến một trong các nút có đường hầm thủ công, trừ khi chúng
có một tuyến đường cụ thể hơn. Theo cách này, một gói IPv4 không bao giờ được gửi đến nút cấp
1, cấp 2, nhưng luôn được gửi qua một trong các đường hầm thủ công.
Bộ định tuyến trong Access DCN kết thúc đường hầm thủ công không cần chạy IS-IS tích hợp. Nó
có thể chạy bất kỳ giao thức định tuyến IP nào mà người vận hành muốn sử dụng. Theo cách này,
mạng hiện có sử dụng OSPF và IS-IS cấp 2 trong Access DCN và IS-IS cấp 1 trong SDH NEs có
thể có các khu vực cấp 1 được nâng cấp thành các khu vực kép mà ít ảnh hưởng đến OSI hiện có
-chỉ SDH NE hoặc trên Access DCN.

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21
76

RUỘT THỪA IIIV

Thư mục

(Phụ lục này không phải là một phần không thể tách rời của Khuyến nghị này)
 IETF RFC 1006 - Dịch vụ truyền tải ISO trên phiên bản TCP: 3 - 5/1997
 IETF RFC 2966 - Phân phối tiền tố trên toàn miền với IS-IS hai cấp - Tháng 10 năm 2000

______________

/CONVERSION/TMP/ACTIVITY_TASK_SCRATCH/535684811.DOCX 07.08.21

You might also like