idnits 2.17.1 draft-zhang-ccamp-gmpls-g709-lmp-discovery-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2012) is 4306 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3945' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC4328' is defined on line 520, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-ccamp-gmpls-g709-framework-08 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-gmpls-g709-framework (ref. 'OTN-frwk') -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G709' -- Possible downref: Non-RFC (?) normative reference: ref. 'G709-V3' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Xian Zhang 3 Intended Status: Standards Track Huawei 4 D. Ceccarelli 5 D. Caviglia 6 Ericsson 7 Guoying Zhang 8 CATR 9 P.Grandi 10 S.Belotti 11 Alcatel-Lucent 13 Expires: January 13 2013 July 12, 2012 15 Link Management Protocol (LMP) extensions for G.709 16 Optical Transport Networks 18 draft-zhang-ccamp-gmpls-g709-lmp-discovery-06.txt 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with 23 the provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 13, 2013. 43 Abstract 44 Recent progress of the Optical Transport Network (OTN) has introduced 45 new signal types (i.e., ODU0, ODU4, ODU2e and ODUflex) and new 46 Tributary Slot granularity (1.25Gbps). 48 Since equipments deployed prior to recently defined ITU-T 49 recommendations only support 2.5 Gbps Tributary Slot granularity and 50 ODU1, ODU2 and ODU3 containers, the compatibility problem should be 51 considered. In addition, a Higher Order ODU (HO ODU) link may not 52 support all the types of Lower Order ODU (LO ODU) signals defined by 53 the new OTN standard because of the limitation of the devices at the 54 two ends of a link. In these cases, the control plane is required to 55 run the capability discovering functions for the evolutive OTN. 57 This document describes the extensions to the Link Management 58 Protocol (LMP) needed to discover the capability of HO ODU link, 59 including the granularity of Tributary Slot to be used and the LO ODU 60 signal types that the link can support. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 Table of Contents 70 1. Introduction ................................................ 3 71 2. Terminology ................................................. 4 72 3. Overview of the Evolutive G.709.............................. 4 73 4. Link Capability Discovery Requirements .......................5 74 4.1. Discovering the Granularity of the TS ...................5 75 4.2. Discovering the Supported LO ODU Signal Types ...........5 76 5. Extensions: LMP Link Summary Message .........................6 77 5.1. Message Extension....................................... 7 78 5.1.1. LinkSummary Message................................ 7 79 5.1.2. LinkSummaryAck Message............................. 7 80 5.1.3. LinkSummaryNack Message............................ 7 81 5.2. Object Definitions...................................... 8 82 5.3. Procedures ............................................ 10 83 6. Security Considerations..................................... 11 84 7. IANA Considerations ........................................ 11 85 8. Acknowledgments ............................................ 11 86 9. References ................................................. 12 87 9.1. Normative References................................... 12 88 9.2. Informative References................................. 12 89 10. Authors' Addresses ........................................ 12 90 11. Contributors .............................................. 14 92 1. Introduction 94 The Link Management Protocol (LMP) defined in [RFC4204] is being 95 developed as part of the Generalized MPLS (GMPLS) protocol suite to 96 manage Traffic Engineering (TE) links. 98 Recently, great progress has been made for the Optical Transport 99 Networking (OTN) technologies in ITU-T. New ODU containers (i.e., 100 ODU0, ODU4, ODU2e and ODUflex) and a new Tributary Slot (TS) 101 granularity (1.25Gbps) have been introduced by the [G709-V3], 102 enhancing the flexibility of OTNs. 104 With the evolution and deployment of G.709 technology, the backward 105 compatibility problem requires to be considered. In data plane, the 106 equipment supporting 1.25Gbps TS can combine the specific Tributary 107 Slots together (e.g., combination of TS#i and TS#i+4 on a HO ODU2 108 link) so that it can interwork with other equipments which support 109 2.5Gbps TS. From the control plane point of view, it is necessary to 110 discover which type of TS is supported at both ends of a link, so 111 that it can choose and reserve the TS resources correctly in this 112 link for the connection. 114 Additionally, the requirement of discovering the signal types of 115 Lower Order ODU (LO ODU) that can be supported by a Higher Order ODU 116 (HO ODU) should be taken into account. Equipment at one end of a HO 117 ODU link may not support to transport some types of LO ODU signals 118 (e.g., may not support the ODUflex). In this case, this HO ODU link 119 should not be selected for those types of LO ODU connections. 121 From the perspective of control plane, it is necessary to discover 122 the capability of a HO ODUk or OTUk link including the granularity of 123 TS to be used and the LO ODU signal types that the link can support. 124 Note that this capability information can be, in principle, 125 discovered by routing. Since in certain case, routing is not present 126 (e.g., UNI case) we need to extend link management protocol 127 capabilities to cover this aspect. Obviously, in case of routing 128 presence, the discovering procedure by LMP could also be optional. 130 This document extends the LMP and describes the solution of 131 discovering HO ODU link capability. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 3. Overview of the Evolutive G.709 141 The traditional OTN standard [ITUT-G709] describes the optical 142 transport hierarchy (OTH) and introduces three ODU signal types (i.e., 143 ODU1, ODU2 and ODU3). The ODUj can be mapped into one or more 144 Tributary Slots (with a granularity of 2.5Gbps) of OPUk where j j) signal can be depicted as follows: 171 - ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity) 173 - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS 174 granularity) 176 - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity) 178 - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing 179 (with 1.25Gbps TS granularity) 181 - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity) 183 - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 184 multiplexing (with 1.25Gbps TS granularity) 186 Note that If TS auto-negotiation is supported, a node supporting 187 1.25Gbps TS can interwork with the other nodes that supporting 188 2.5Gbps TS by combining specific TSs together in data plane, as 189 descirbied in [OTN-frwk]. 191 4. Link Capability Discovery Requirements 193 4.1. Discovering the Granularity of the TS 195 As described in section 3.1, if the two ends of a link use different 196 granularities of TS, The LO ODU must be mapped into specific combined 197 Tributary Slots in the end of link with TS of 1.25Gbps. 199 From the perspective of control plane, when creating a LO ODU 200 connection, the node MUST select and reserve specific TS for the 201 connection if the two ends of a link use different granularities of 202 TS. For example, for an ODU2 link, we suppose that node A only 203 supports the 2.5Gbps TS while node B supports the 1.25Gbps TS. When 204 node B receives a Path message from node A requesting an ODU1 205 connection, node B MUST reserve the TS#i and TS#i+4 (where i<=4) 206 (with the granularity of 1.25Gbps) and tell node A via the label 207 carried in the Resv message that the TS#i (with the granularity of 208 2.5Gbps) among the 4 slots has been reserved for the ODU1 connection. 209 Otherwise, the reservation procedure will fail. 211 +-----+ Path +-----+ 212 | | ------------> | | 213 | A +-------ODU2 link-------+ B | 214 | | <------------- | | 215 +-----+ Resv +-----+ 216 (Support 2.5G TS) (Support 1.25G TS) 218 Therefore, for an ODU2 or ODU3 link, in order to reserve TS resources 219 correctly for a LO ODU connection, the control plane of the two ends 220 MUST know which granularity the other end can support before creating 221 the LO ODU connection. 223 4.2. Discovering the Supported LO ODU Signal Types 225 Many new ODU signal types are introduced by [G709-V3], such as ODU0, 226 ODU4, ODU2e and ODUflex. It is possible that equipment does not 227 always support all the LO ODU signal types introduced by [G709-V3]. 229 If one end of a HO ODU link can not support a certain LO ODU signal 230 type and there is no HO ODU FA LSP able to support this LO ODU signal, 231 the HO ODU link/FA LSP can not be selected to carry such type of LO 232 ODU connection. 234 For example, in the following figure, if the interfaces IF1, IF2, IF8, 235 IF7, IF5 and IF6 can support ODUflex signals, while the interfaces IF 236 3 and IF4 can not support ODUflex signals. In this case, if one 237 ODUflex connection from A to C is requested, and there is no HO ODU 238 FA LSP from node A to C through node B, link #1 and #2 should be 239 excluded, link #3 and link #4 are the candidates (the possible path 240 could be A-D-C through link #3 and link #4). 242 +-----+ 243 link #3 | | link #4 244 +-----------------+ D +-----------------+ 245 | IF8| |IF7 | 246 | +-----+ | 247 | | 248 |IF1 IF6| 249 +--+--+ +-----+ +--+--+ 250 | | link #1 | | link #2 | | 251 | A +--------------+ B +--------------+ C | 252 | |IF2 IF3| |IF4 IF5| | 253 +-----+ +-----+ +-----+ 255 Therefore, it is necessary for the two ends of a HO ODU link to 256 discover which types of LO ODU can be supported by the HO ODU link. 257 After discovering, the capability information can be flooded by IGP, 258 so that the correct path for an ODU connection can be calculated. 260 5. Extensions: LMP Link Summary Message 262 [RFC4204] defines the Link Management Protocol (LMP) which consists 263 of four main procedures: control channel management, link property 264 correlation, link connectivity verification, and fault management. As 265 part of LMP, the link property correlation is used to verify the 266 consistency of the TE and data link information on both sides of a 267 link. This document extends the link property correlation procedure 268 to discover the capability of both sides of a HO ODU link. 270 The designated HO ODU overhead bytes (e.g., the GCC1 and GCC2 271 overhead bytes) can be used as the control channel to carry the LMP 272 message after the HO ODU link is created. The out-of-band Data 273 Communication Network (DCN) can also be used. 275 5.1. Message Extension 277 Three messages are used for link property correlation: LinkSummary, 278 LinkSummaryAck and LinkSummaryNack Message. This document does not 279 change the basic procedure of LMP but just add a new subobject (HO 280 ODU Link Capability) in the DATA_LINK object to carry the capability 281 of one end of a HO ODU link. 283 The formats of LinkSummary, LinkSummaryAck and LinkSummaryNack 284 messages are defined in [RFC4204]. 286 5.1.1. LinkSummary Message 288 The local end of a TE link can send a LinkSummary message to the 289 remote end to start the negotiation about the capability that the TE 290 link can support. 292 One new Subobject named HO ODU Link Capability Subobject in the 293 DATA_LINK object is introduced by this document. This new subobect is 294 used to tell the remote end of the HO ODU link which TS granularity 295 and which LO ODU signal types that the local end can support. When 296 the DATA_LINK object carries the new HO ODU Link Capability Subobject, 297 the N flag SHOULD be set to 1 which means that the subobject is 298 negotiable. 300 5.1.2. LinkSummaryAck Message 302 The LinkSummaryAck message is used to tell the remote end that it has 303 the same capability as the remote end after the LinkSummary message 304 is received by the local end. 306 5.1.3. LinkSummaryNack Message 308 The LinkSummaryNack message is used to tell the remote end that it 309 has different capability from the remote end after the LinkSummary 310 message is received by the local end. The LinkSummaryNack message 311 also carries the HO ODU Link Capability subobject in the DATA_LINK 312 object to tell the remote end the exact capability of the HO ODU link 313 after negotiation, i.e., the granularity of TS and the types of LO 314 ODU that both side of the HO ODU link can support. 316 5.2. Object Definitions 318 A new HO ODU Link Capability subobject type is introduced to the DATA 319 LINK object to carry the HO ODU link capability information. The 320 format of the new subobject is defined as follow: 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type | Length |OD(T)Uk| T | Reserved | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |A|B|C|D|E|F|G| LO ODU Flags | Reserved | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Type (8 bits): 332 The value of this subobject type is TBD. 334 Length (8 bits): 336 The Length field contains the total length of the subobject in bytes, 337 including the Type and Length fields. As for RFC 4204, the Length 338 MUST be at least 4, and MUST be a multiple of 4. Value of this field 339 is 8. 341 OD(T)Uk (4 bits): 343 This field is used to indicate the HO ODU link type (in case of LO 344 ODUj multiplexing into HO ODUk, wherein j