1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T G.7712/Y.1703 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Amendment 2 (02/2016) SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS Data over Transport Generic aspects Transport network control aspect
2、s SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS, INTERNET OF THINGS AND SMART CITIES Internet protocol aspects Operation, administration and maintenance Architecture and specification of data communication network Amendment 2 Recommendation ITU-T
3、 G.7712/Y.1703 (2010) Amendment 2 ITU-T G-SERIES RECOMMENDATIONS TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100G.199 GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER-TRANSMISSION SYSTEMS G.200G.299 INDIVIDUAL CHARACTERISTICS
4、OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS ON METALLIC LINES G.300G.399 GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH METALLIC LINES G.400G.449 COORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY G.450G.499 TRANSMISSION ME
5、DIA AND OPTICAL SYSTEMS CHARACTERISTICS G.600G.699 DIGITAL TERMINAL EQUIPMENTS G.700G.799 DIGITAL NETWORKS G.800G.899 DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900G.999 MULTIMEDIA QUALITY OF SERVICE AND PERFORMANCE GENERIC AND USER-RELATED ASPECTS G.1000G.1999 TRANSMISSION MEDIA CHARACTERISTICS G.6
6、000G.6999 DATA OVER TRANSPORT GENERIC ASPECTS G.7000G.7999 General G.7000G.7099 Transport network control aspects G.7700G.7799 PACKET OVER TRANSPORT ASPECTS G.8000G.8999 ACCESS NETWORKS G.9000G.9999 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T G.7712/Y.1703 (201
7、0)/Amd.2 (02/2016) i Recommendation ITU-T G.7712/Y.1703 Architecture and specification of data communication network Amendment 2 Summary Amendment 2 to Recommendation ITU-T G.7712/Y.1703 contains the updates to Recommendation ITU-T G.7712/Y.1703 (2010) to provide the specification of the out-of-band
8、 (OOB) OCh overhead (OCh-O) status report protocol (SRP). History Edition Recommendation Approval Study Group Unique ID* 1.0 ITU-T G.7712/Y.1703 2001-11-29 15 11.1002/1000/5637 2.0 ITU-T G.7712/Y.1703 2003-03-16 15 11.1002/1000/6287 3.0 ITU-T G.7712/Y.1703 2008-06-22 15 11.1002/1000/9390 4.0 ITU-T G
9、.7712/Y.1703 2010-09-06 15 11.1002/1000/10895 4.1 ITU-T G.7712/Y.1703 (2010) Amd. 1 2013-10-07 15 11.1002/1000/12000 4.2 ITU-T G.7712/Y.1703 (2010) Amd. 2 2016-02-26 15 11.1002/1000/12553 * To access the Recommendation, type the URL http:/handle.itu.int/ in the address field of your web browser, fol
10、lowed by the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/1000/11830-en. ii Rec. ITU-T G.7712/Y.1703 (2010)/Amd.2 (02/2016) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and co
11、mmunication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis.
12、 The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resoluti
13、on 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and
14、 a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are me
15、t. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibi
16、lity that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Rec
17、ommendation development process. As of the date of approval of this Recommendation, ITU had received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information a
18、nd are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2016 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T G.7712/Y.1703 (2010)/Amd.2 (02/2016) iii T
19、able of Contents Page 1) Scope . 1 2) Updates to Recommendation ITU-T G.7712/Y.1703 . 1 2.1) Clause 2, References 1 2.2) Clause 4, Abbreviations 1 2.3) Clause 6.3.1 1 2.4) Add a new Annex D . 1 Annex D OOB OCh-O protocol specification 1 D.1 Overview 1 D.2 PDU format 2 D.3 OCh_O communication channel
20、 adaptation function (OCC/OCh-O_A) . 6 D.4 OCh_O communication channel termination function (OCC_TT) 6 Rec. ITU-T G.7712/Y.1703 (2010)/Amd.2 (02/2016) 1 Recommendation ITU-T G.7712/Y.1703 Architecture and specification of data communication network Amendment 2 1) Scope This amendment contains the up
21、dates to Recommendation ITU-T G.7712/Y.1703 (2010) to provide the specification of the out-of-band (OOB) OCh overhead (OCh-O) status report protocol (SRP). 2) Updates to Recommendation ITU-T G.7712/Y.1703 2.1) Clause 2, References Add the following reference to clause 2: IETF RFC 4204 IETF RFC 4204
22、(2005), Link Management Protocol (LMP). 2.2) Clause 4, Abbreviations Add the following abbreviations, inserted alphabetically, to clause 4: LMP Link Management Protocol OOB Out-Of-Band OPS Optical Physical Section UDP User Datagram Protocol 2.3) Clause 6.3.1 Update to clause 6.3.1, “OCh overhead com
23、munication application“ Replace the note: NOTE The specification for how the primitive and information elements described in Amendment 2 of ITU-T G.709 are carried across an OCN is for further study. with the following text: The protocol used for OCh overhead communication is defined in Annex D. 2.4
24、) Add a new Annex D Insert the following text as a new Annex D: Annex D OOB OCh-O protocol specification (This annex forms an integral part of this Recommendation.) D.1 Overview The OOB OCh-O protocol supports an OCC carrying the status of OCh connections and signals over an OCN to systems that do n
25、ot have direct access to the OSC. For deployment flexibility, the OCh-O 2 Rec. ITU-T G.7712/Y.1703 (2010)/Amd.2 (02/2016) protocol is defined independent of the specific DCN protocol in use (e.g., IPv4, IPv6). The details of how to adapt the characteristic information (CI) of this protocol to an IPv
26、4-based DCN are provided at the end of the protocol definition. The OOB OCh-O protocol requires configuration of a protocol adjacency between two OCh-O connection points (OCh-O CP) located on the associated network equipment being connected by one or more optical physical section (OPS). Prior to bot
27、h ends being configured, the status reporting behaviours driven by the protocol will not be operational. The adjacency is identified by using OPS as well as OCh identifiers and is carried by the DCN network. The status messages carried by the OOB OCh-O protocol provide unidirectional state informati
28、on for one or more OCh connections and signals. The messages include identifiers of the OPS trail and one or more OCh-P link connections carried by that trail that identify the OCh-P link connections for which status is being reported. The receiving NE correlates the received status message with a l
29、ocal OCh-P CP utilizing the configured OPS adjacency. D.2 PDU format The OOB OCh-O protocol is derived from the IETFs link management protocol (LMP) IETF RFC 4204. LMP uses a common format for the PDUs of all protocol messages as shown in Figure D.1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
30、 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | (Reserved) | Flags | Msg Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Length | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Payload
31、TLVs : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure D.1 OOB OCh-O protocol message PDU format Sub-protocols are used in the design of the OOB OCh-O protocol. The value in the Msg Type field indicates which of the sub-protocols a PDU belongs to. TLV structure is used for t
32、he base PDU and payload TLV structures; in all cases the units of length are octets. The Msg Length provides the overall length of the PDU. Payload TLVs follow the format shown in Figure D.2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
33、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C-Type | Class | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Value : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure D.2 OOB OCh-O protocol payload TLV format The C-Type and Class fields are defined by each sub
34、-protocol. The Length field provides the overall length of the TLV inclusive of the C-Type, Class and Length fields. The OOB OCh-O protocol shall exchange Hello PDUs and Status Reporting PDUs. Rec. ITU-T G.7712/Y.1703 (2010)/Amd.2 (02/2016) 3 D.2.1 Hello sub-protocol The Hello sub-protocol uses a me
35、ssage type of 4. Inside the message are Hello sequence and validity TLVs. The format of these TLVs is as follows: D.2.1.1 Hello sequence TLV The C-type is 7, Class is 1 and Length is 12. The Value field is formatted as shown in Figure D.3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
36、6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RcvSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure D.3 OOB OCh-O protocol Hello sequence format The TxSeqNu
37、m is the sequence number of the Status Reporting message last transmitted by this adjacency endpoint. The RcvSeqNum is the sequence number of the Status Reporting message last received by this adjacency endpoint. Initially the RcvSeqNum=0 and the TxSeqNum=1. The RcvSeqNum will be replaced with the T
38、xSeqNum received from the peer when the first Hello message is received. If a Hello message is received with a Hello sequence TLV containing a RcvSeqNum equal to 0, it is an indication that the peer endpoint has restarted and requires state information be sent for all OCh associated with this adjace
39、ncy. The TxSeqNum may eventually exceed 232. When this occurs, the TxSeqNum will wrap to the value of 1. D.2.1.2 Hello validity TLV The C-type is 240, Class is 1 and Length is 8. The value is formatted as shown in Figure D.4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-
40、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Validity Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure D.4 OOB OCh-O protocol Hello validity format The Validity Period field describes the amount of time (in ms) before another Hello must be receiv
41、ed for the adjacency to be considered up. A transmitter should send subsequent Hello messages prior to the expiration of the validity period. The receiver of the Hello must update the expiration of the adjacency health timer upon receipt of a Hello PDU. If the validity period expires, the adjacency
42、shall raise an alarm to the EMF. This alarm clears when the Hello protocol receives a Hello message from the peer starting a new validity period. D.2.2 Status Reporting sub-protocol Status Reporting PDUs are issued for one or more OCh connections and signals as state changes occur or initial state r
43、equests are received. These PDUs use message type 17. The PDUs each contain a Message ID TLV, an OPS Trail Identification TLV, along with one or more identifiers for one or more OCh-P Link Connections and one OCh Status TLVs. It is possible for multiple OCh-P link connections that change state at th
44、e same time to be reported in a single Status Reporting PDU. In this case, all OCh-Ps identified in the PDU will have the same status. 4 Rec. ITU-T G.7712/Y.1703 (2010)/Amd.2 (02/2016) The format of these TLVs is as follows: D.2.2.1 Message ID TLV The Message ID TLV contains the TxSeqNum for this sp
45、ecific Status Reporting PDU. The Class number is 5 and the C-Type 1. The TLV Length is 8. The format is shown in Figure D.5. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message_ID | +-+-+-+-+-+-+-+-+-+-+-
46、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure D.5 OOB OCh status reporting Message ID format D.2.2.2 OPS Trail Identification TLV The namespace used for OPS Trail Identification is the TCP_ID namespace used by ITU-T G.7714 neighbour discovery. Control plane names are not used as it is not guara
47、nteed that a control plane is active on this link. An OPS Trail Identification TLV has a C-type of 241 and Length of 16. The class uses the Format ID defined for each TCP-ID format in ITU-T G.7714.1. The Value field is formatted as shown in Figure D.6, Figure D.7 and Figure D.8 for TCP-ID Name, DCN
48、Address format and DCN Name formats respectively. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Reserved) | TCP Name . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . TCP Name . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . TCP Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
