idnits 2.17.1 draft-ietf-mpls-tp-gach-dcn-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group D. Beller 2 Internet-Draft Alcatel-Lucent 3 Intended Status: Standards Track A. Farrel 4 Created: August 14, 2009 Old Dog Consulting 5 Expires: February 14, 2010 7 An Inband Data Communication Network For the MPLS Transport Profile 9 draft-ietf-mpls-tp-gach-dcn-04.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The Generic Associated Channel (G-ACh) has been defined as a 35 generalization of the pseudowire (PW) associated control channel to 36 enable the realization of a control/communication channel associated 37 with Multiprotocol Label Switching (MPLS) Label Switched Paths 38 (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between 39 adjacent MPLS-capable devices. 41 The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS 42 architecture that identifies elements of the MPLS toolkit that may be 43 combined to build a carrier grade packet transport network based on 44 MPLS packet switching technology. 46 This document describes how the G-ACh may be used to provide the 47 infrastructure that forms part of the Management Communication 48 Network (MCN) and a Signaling Communication Network (SCN). 49 Collectively, the MCN and SCN may be referred to as the Data 50 Communication Network (DCN). This document explains how MCN and SCN 51 messages are encapsulated, carried on the G-ACh, and demultiplexed 52 for delivery to the management or signaling/routing control plane 53 components on an MPLS-TP node. 55 It should be noted that the use of the G-ACh to provide connectivity 56 for the DCN is intended for use only where the MPLS-TP network is not 57 capable of encapsulating or delivering native DCN messages. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC-2119 [RFC2119]. 65 1. Introduction 67 The associated channel header (ACH) is specified in [RFC4385]. It is 68 a packet header format for use on pseudowires (PWs) in order to 69 identify packets used for OAM and similar functions. 71 The use of the ACH is generalized in [RFC5586] and can be applied on 72 any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP). 73 This is referred to as the Generic Associated Channel (G-ACh) and is 74 intended to create a control/management communication channel 75 associated with the LSP that can be used to carry packets used for 76 OAM and similar functions (e.g., control/management plane messages). 78 The purpose of a packet carried on the G-ACh is indicated by the 79 value carried by the Channel Type field of the ACH and a registry of 80 values is maintained by IANA ([RFC4446] and [RFC4385]). The 81 combination of the ACH and the ACH TLVs that may be appended to the 82 ACH is referred in this document as the G-ACh header. 84 The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in 85 [TP-REQ]. MPLS-TP is the application of MPLS to construct a packet 86 transport network. It constitutes a profile of MPLS that enables 87 operational models typical in transport networks, which includes 88 additional OAM, survivability and other maintenance functions not 89 previously supported by MPLS. 91 Label Switching Routers (LSRs) in MPLS networks may be operated using 92 management protocols or control plane protocols. Messaging in these 93 protocols is normally achieved using IP packets exchanged over IP- 94 capable interfaces. However, some nodes in MPLS-TP networks may be 95 constructed without support for direct IP encapsulation on their 96 line-side interfaces, and without access to an out-of-fiber data 97 communication network. In order that such nodes can communicate using 98 management plane or control plane protocols, channels must be 99 provided, and the only available mechanism is to use an MPLS label. 101 The G-ACh provides a suitable mechanism for this purpose, and this 102 document defines processes and procedures to allow the G-ACh to be 103 used to build a management communication network (MCN) and a 104 signaling communication network (SCN) together known as the data 105 communication network (DCN) [G.7712]. 107 1.1. Requirements 109 The requirements presented in this section are based on those 110 communicated to the IETF by the ITU-T. 112 1. A packet encapsulation mechanism must be provided to support the 113 transport of MCN and SCN packets over the G-ACh. 115 2. The G-ACh carrying the MCN and SCN packets shall support the 116 following application scenarios: 118 a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when 119 the server layer does not provide a Management Communication 120 Channel (MCC) or a Signalling Communication Channel (SCC)). 122 b. The G-ACh is carried by an MPLS-TP tunnel that traverses 123 another operator's domain (carrier's carrier scenario) 125 3. The G-ACh shall provide two independent channels: an MCC to build 126 the MCN and an SCC to build the SCN. The G-ACh packet header shall 127 indicate whether the packet is an MCC or an SCC packet in order to 128 forward it to the management or control plane application for 129 processing. 131 4. The channel separation mechanism shall allow the use of separate 132 rate limiters and traffic shaping functions for each channel (MCC 133 and SCC) ensuring that the flows do not exceed their assigned 134 traffic profiles. The rate limiters and traffic shapers are 135 outside the scope of the MCC and SCC definitions. 137 5. The G-ACh that carries the MCC and SCC shall be capable of 138 carrying different OSI layer 3 (network layer) PDUs. These shall 139 include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC 140 packet shall indicate which layer 3 PDU is contained in the 141 payload field of the packet such that the packet can be delivered 142 to the related layer 3 process within the management and control 143 plane application, respectively, for further processing. 145 6. The G-ACh is not required to provide specific security mechanisms. 146 However, the management or control plane protocols that operate 147 over the MCC or SCC are required to provide adequate security 148 mechanisms in order not to be susceptible to security attacks. 150 2. Procedures 152 Figure 1 depicts the format of an MCC/SCC packet that is sent on the 153 G-ACh. The Channel Type field indicates the function of the ACH 154 message so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC 155 message is prepended with an ACH with the Channel Type set to 156 indicate that the message is an MCC or SCC message. The ACH MUST 157 include the ACH Protocol ID TLV [ACH-TLV] to identify the protocol 158 type of the MCC or SCC message, and MAY include further ACH TLVs. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 |0 0 0 1|Version| Reserved | Channel Type | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | ACH TLV Header | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 ~ zero or more ACH TLVs ~ 168 ~ ~ 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | ACH Protocol ID TLV | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | MCC/SCC Message | 173 ~ ~ 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 1: G-ACh MCC/SCC Packet 178 o The Channel Type field determines whether the message is an MCC or 179 an SCC message. See Section 5 for the codepoint assignments. 181 o No other ACH TLVs (except the ACH protocol ID TLV - see below) has 182 been identified for use on a DCN message. If a message is received 183 carrying an ACH TLV that is not understood in the context of a DCN 184 message, the ACH TLV SHOULD be silently ignored and processing of 185 the message SHOULD continue. 187 o The ACH Protocol ID TLV identifies the PDU type of the MCC/SCC 188 message. The ACH MUST be present in a DCN message and MUST be 189 placed last in the sequence of ACh TLVs so that it comes 190 immediately before the MCC/SCC message. Note that this means that 191 the PID field of the TLV is immediately adjacent to the message 192 iteslf. 194 The ACH Protocol ID TLV is defined in [ACH-TLV] and uses the PPP 195 protocol identifiers to distinguish different protocols [RFC1661], 196 [RFC3818]. 198 When the G-ACh sender receives an MCC message that is to be sent over 199 the MCC, the sender creates the G-ACh header, provides an ACH 200 Protocol ID TLV indicating the MCC layer 3 PDU type, sets the Channel 201 Type field to MCC, and prepends the MCC message with the G-ACh 202 header. The same procedure is applied when a control plane message is 203 to be sent over the SCC. In this case, the sender sets the Channel 204 Type field to SCC. 206 If the G-ACh is associated with an MPLS section, the GAL is added to 207 the message as defined in [RFC5586]. The TTL field MUST be set to 1, 208 and the S-bit of the GAL MUST be set to 1. 210 If the G-ACh is associated with an LSP, the GAL is added to the 211 packet and the LSP label is pushed on top of the GAL as defined in 212 [RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit 213 of the GAL MUST be set to 1. 215 The DCN channel MUST NOT be used to transport user traffic and SHALL 216 only be used to carry management or control plane messages. 217 Procedures that ensure this (such as deep packet inspection) are 218 outside the scope of this specification. 220 When a receiver has received a packet on the G-ACh with the ACH 221 Channel Type set to MCC or SCC, it SHALL look at the PID field 222 carried in the ACH Protocol ID TLV. If the TLV is absent, the message 223 SHALL be silently discarded, although a local system MAY increment a 224 counter that records discarded or errored packets, and MAY log an 225 event. If the PID value is known by the receiver it SHALL deliver the 226 entire packet including the MCC/SCC message to the appropriate 227 processing entity. If the PID value is unknown, the receiver SHALL 228 silently discard the received packet, MAY increment a counter that 229 records discarded or errored messages, and MAY log an event. 231 It must be noted that according to [RFC5586] a receiver MUST NOT 232 forward a GAL packet based on the GAL label as is normally the case 233 for MPLS packets. If the GAL appears at the bottom of the label 234 stack, it MUST be processed as described in the previous paragraph. 236 Note that there is no requirement for MPLS-TP devices to support IP 237 or OSI forwarding in the fast (forwarding) path. Thus, if a message 238 is received on the MCC or SCC and is not targeted to an address of 239 the receiving MPLS-TP node, the node MUST NOT forward the packet in 240 the fast path. The node SHOULD apply layer 3 forwarding procedures 241 in the slow path and MAY discard or rehect the message using the 242 layer 3 protocol if it is unable to forward it. 244 2.1. Pseudowire Setup 246 Provider Edge nodes may wish to set up PWs using a singaling protocol 247 that uses remote adjacencies (such as LDP [RFC5036]). In the absence 248 of an IP-based control plane network, these PEs MUST first set up an 249 LSP tunnel across the MPLS-TP network. This tunnel can be used both 250 to carry the PW once it has been set up and to provide a G-ACh based 251 DCN for control plane communications between the PEs. 253 3. Applicability 255 The DCN is intented to provide connectivity between management 256 stations and network nodes, and between pairs of network nodes, for 257 the purpose of exchanging management plane and control plane 258 messages. 260 Appendix A of [NM-REQ] describes how Control Channels (CCh) that are 261 the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in- 262 fiber and out-of-band, or in-band with respect to the user data 263 carried by the MPLS-TP network. The Appendix also explains how the 264 DCN can be constructed from a mix of different types of links and 265 how routing and forwarding can be used within the DCN to facilitate 266 multi-hop delivery of management and control plane messages. 268 The G-ACh used as described in this document allows the creation of 269 a "data channel associated CCh" (type 6 in Appendix A of [NM-REQ]) 270 and an "in-band CCh" (type 7 in Appendix A of [NM-REQ]). In the 271 former case, the G-ACh is associated with an MPLS-TP section. In the 272 latter case, the G-ACh is associated with an MPLS-TP LSP or PW and 273 may span one or more hops in the MPLS-TP network. 275 4. Security Considerations 277 The G-ACh provides a virtual link between MPLS-TP nodes and might be 278 used to induce many forms of security attack. Protocols that operate 279 over the MCN or SCN are REQUIRED to include adequate security 280 mechanisms and implementations MUST allow operators to configure the 281 use of those mechanisms. 283 5. IANA Considerations 285 Channel Types for the Generic Associated Channel are allocated from 286 the IANA PW Associated Channel Type registry defined in [RFC4446] and 287 updated by [RFC5586]. 289 IANA is requested to allocate two further Channel Types as follows: 290 xx Management Communication Channel (MCC) 291 yy Signaling Communication Channel (SCC) 293 6. Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge 299 (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, 300 February 2006. 302 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 303 Emulation (PWE3)", RFC 4446, April 2006 . 305 [RFC5586] Bocci, M., Vigoureux, M., and Bryant, S., "MPLS Generic 306 Associated Channel", RFC 5586, June 2009. 308 [ACH-TLV] Bryant, S., et al., "Definition of ACH TLV Structure", 309 draft-bryant-mpls-tp-ach-tlv, work in progress. 311 7. Informative References 313 [MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS 314 in Transport Networks", draft-ietf-mpls-tp-framework, work 315 in progress. 317 [TP-REQ] B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., 318 N. Sprecher, S. Ueno, "MPLS-TP Requirements", 319 draft-ietf-mpls-tp-requirements, work in progress. 321 [NM-REQ] Lam, H.-K., Mansfield, S., and Gray, E., "MPLS TP Network 322 Management Requirements", draft-ietf-mpls-tp-nm-req, work 323 in progress. 325 [G.7712] ITU-T Recommendation G.7712, "Architecture and 326 specification of data communication network", June 2008. 328 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 329 RFC 1661, July 1994. 331 [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point 332 Protocol (PPP)", BCP 88, RFC 3818, June 2004. 334 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 335 Specification", RFC 5036, October 2007. 337 8. Acknowledgements 339 The editors wish to thank Pietro Grandi, Martin Vigoureux, and Kam 340 Lam for their contribution to this document, and the MEAD team for 341 thorough review. 343 9. Authors' Addresses 345 Dieter Beller 346 Alcatel-Lucent Germany 347 EMail: dieter.beller@alcatel-lucent.com 349 Adrian Farrel 350 Old Dog Consulting 351 EMail: adrian@olddog.co.uk 353 Full Copyright Statement 355 The IETF Trust takes no position regarding the validity or scope of 356 any Intellectual Property Rights or other rights that might be 357 claimed to pertain to the implementation or use of the technology 358 described in any IETF Document or the extent to which any license 359 under such rights might or might not be available; nor does it 360 represent that it has made any independent effort to identify any 361 such rights. 363 Copies of Intellectual Property disclosures made to the IETF 364 Secretariat and any assurances of licenses to be made available, or 365 the result of an attempt made to obtain a general license or 366 permission for the use of such proprietary rights by implementers or 367 users of this specification can be obtained from the IETF on-line IPR 368 repository at http://www.ietf.org/ipr 370 The IETF invites any interested party to bring to its attention any 371 copyrights, patents or patent applications, or other proprietary 372 rights that may cover technology that may be required to implement 373 any standard or specification contained in an IETF Document. Please 374 address the information to the IETF at ietf-ipr@ietf.org. 376 The definitive version of an IETF Document is that published by, or 377 under the auspices of, the IETF. Versions of IETF Documents that are 378 published by third parties, including those that are translated into 379 other languages, should not be considered to be definitive versions 380 of IETF Documents. The definitive version of these Legal Provisions 381 is that published by, or under the auspices of, the IETF. Versions of 382 these Legal Provisions that are published by third parties, including 383 those that are translated into other languages, should not be 384 considered to be definitive versions of these Legal Provisions. 386 For the avoidance of doubt, each Contributor to the IETF Standards 387 Process licenses each Contribution that he or she makes as part of 388 the IETF Standards Process to the IETF Trust pursuant to the 389 provisions of RFC 5378. No language to the contrary, or terms, 390 conditions or rights that differ from or are inconsistent with the 391 rights and licenses granted under RFC 5378, shall have any effect and 392 shall be null and void, whether published or posted by such 393 Contributor, or included with or in such Contribution. 395 Disclaimer of Validity 397 All IETF Documents and the information contained therein are provided 398 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 399 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 400 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 401 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 402 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 403 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 404 FOR A PARTICULAR PURPOSE. 406 Full Copyright Statement 408 Copyright (c) 2009 IETF Trust and the persons identified as the 409 document authors. All rights reserved. 411 This document is subject to BCP 78 and the IETF Trust's Legal 412 Provisions Relating to IETF Documents in effect on the date of 413 publication of this document (http://trustee.ietf.org/license-info). 414 Please review these documents carefully, as they describe your 415 rights and restrictions with respect to this document.