idnits 2.17.1 draft-ietf-mpls-tp-gach-dcn-01.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 information found for draft-bryant-xxxx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ACH-TLV' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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: May 8, 2009 Old Dog Consulting 5 Expires: November 8, 2009 7 An Inband Data Communication Network For the MPLS Transport Profile 9 draft-ietf-mpls-tp-gach-dcn-01.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 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). The document explains how MCN and SCN 51 packets are encapsulated, carried on the G-ACh, and demultiplexed for 52 delivery to the management or signaling/routing components on a label 53 switching router (LSR). 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 encapsulating or delivering native DCN messages. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 62 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 63 "OPTIONAL" in this document are to be interpreted as described in 64 RFC-2119 [RFC2119]. 66 1. Introduction 68 The associated channel header (ACH) is specified in [RFC4385]. It is 69 a packet header format for use on pseudowire (PW) packets in order to 70 identify packets used for OAM and similar functions. 72 The use of the ACH is generalized to apply on any Multiprotocol Label 73 Switching (MPLS) Label Switching Path (LSP) in [GAL-GACH]. The 74 generalized concept is referred to as the Generic Associated Channel 75 (G-ACh) and is intended to create a control/communication channel 76 associated with the LSP that can be used to carry packets used for 77 OAM and similar functions (e.g., control plane messages). 79 The purpose of a packet carried on the G-ACh is indicated by the 80 value carried by the Channel Type field of the ACH and a registry of 81 values is maintained by IANA [RFC4446]. 83 The MPLS transport profile (MPLS-TP) is described in [MPLS-TP]. 84 MPLS-TP is the application of MPLS to construct a packet transport 85 network. It constitutes a profile of MPLS that enables operational 86 models typical in transport networks, which includes additional OAM, 87 survivability and other maintenance functions not previously 88 supported by MPLS. 90 Label Switching Routers in MPLS networks may be operated using 91 management protocols or control plane protocols. Messaging in these 92 protocols is normally achieved using IP packets exchanged over IP- 93 capable interfaces. However, some LSRs in MPLS-TP networks may be 94 constructed without support for direct IP encapsulation on their 95 line-side interfaces and without access to an out-of-fiber data 96 communication network. In order that such LSRs can communicate using 97 management plane or control plane protocols channels must be provided 98 and the only available mechanism is to use an MPLS label. 100 The G-ACh provides a suitable mechanism, and this document defines 101 processes and procedures to allow the G-ACh to be used to build a 102 management communication network (MCN) and a signaling communication 103 network (SCN) together known as the data communication network (DCN) 104 [G.7712]. 106 1.1. Requirements 108 The requirements presented in this section are based on those 109 communicated to the IETF by the ITU-T. 111 1. A packet encapsulation mechanism must be provided to support the 112 transport of MCN and SCN packets over the G-ACh. 114 2. The G-ACh carrying the MCN and SCN packets shall support the 115 following application scenarios: 117 a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when 118 the server layer does not provide a Management Communication 119 Channel (MCC) or a Signalling Communication Channel (SCC)). 121 b. The G-ACh is carried by a MPLS-TP tunnel that traverses another 122 operator's domain (carrier's carrier scenario) 124 3. The G-ACh shall provide two independent channels: a MCC to build 125 the MCN and a SCC to build the SCN. The G-ACh packet header shall 126 indicate whether the packet is a MCC or an SCC packet in order to 127 forward it to the management or control plane application for 128 processing. 130 4. The channel separation mechanism shall allow the use of separate 131 rate limiters and traffic shaping functions for each channel (MCC 132 and SCC) ensuring that the flows do not exceed their assigned 133 traffic profile. The rate limiter and traffic shaper are outside 134 the scope of the MCC and SCC definition. 136 5. The G-ACh that carries the MCC and SCC shall be capable of 137 carrying different OSI layer 3 (network layer) PDUs. These shall 138 include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC 139 packet shall indicate which layer 3 PDU is contained in the 140 payload field of the packet such that the packet can be forwarded 141 to the related layer 3 process within the management and control 142 plane application, respectively, for further processing. 144 6. The G-ACh is not required to provide specific security mechanisms. 145 However, the management or control plane protocols that operate 146 over the MCC or SCC are required to provide adequate security 147 mechanisms in order not to be susceptible to security attacks. 149 2. Procedures 151 Figure 1 depicts the format of an MCC/SCC packet that is sent on the 152 G-ACh. To send an MCC/SCC packet on the G-ACh, the MCC/SCC packet is 153 prepended with the ACH and one or more ACH TLVs [GAL-GACH], and MUST 154 include the ACH Protocol ID TLV [ACH-TLV] to identify the protocol 155 type of the MCC or SCC packet. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 |0 0 0 1|Version| Reserved | Channel Type | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | ACH TLV Header | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | ACH Protocol ID TLV | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 ~ zero or more other ACH TLVs ~ 167 ~ ~ 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | MCC/SCC Packet | 170 ~ ~ 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1: MCC/SCC Packet with Associated Channel Header 175 o The Channel Type field determines whether the message is an MCC or 176 an SCC message. See Section 4 for the codepoint assignments. 178 o The ACH Protocol ID TLV identifies the PDU type of the MCC/SCC 179 message. The ACH Protocol ID TLV is defined in [ACH-TLV] and uses 180 the PPP protocol identifiers to distinguish different protocols. 182 When the G-ACh sender receives an MCC message that is to be sent over 183 the MCC, the sender creates the G-ACh header, provides an ACH 184 Protocol ID TLV indicating the MCC layer 3 PDU type, sets the Channel 185 Type field to MCC, and prepends the MCC message with the G-ACh 186 header. The same procedure is applied when a control plane message is 187 to be sent over the SCC. In this case, the sender sets the Channel 188 Type field to SCC. 190 If the MPLS section G-ACh is used, the GAL is added to the packet as 191 defined in [GAL-GACH]. The TTL field MUST be set to 1, and the S-bit 192 of the GAL MUST be set to 1. 194 If the G-ACh is associated with an LSP, the GAL is added to the 195 packet and the LSP label is pushed on top of the GAL as defined in 197 [GAL-GACH]. The TTL field of the GAL SHOULD be set to 1, and the 198 S-bit of the GAL MUST be set to 1. 200 The DCN channel MUST NOT be used to trnasport user traffic and SHALL 201 only be used to carry management or control plane messages. 202 Procedures that ensure this such as deep packet inspection are 203 outside the scope of this specification. 205 When a receiver has received a packet on the G-ACh with the ACH 206 Channel Type set to MCC or SCC, it SHALL look at the PID field 207 carried in the ACH Protocol ID TLV. If the TLV is absent, the message 208 SHALL be silently discarded although a local system MAY increment a 209 counter or raise an event log. If the PID value is known by the 210 receiver it SHALL deliver the entire packet including the MCC/SCC 211 message to the appropriate processing entity. If the PID value is 212 unknown, the receiver SHALL silently discard the received Packet and 213 MAY increment a counter or raise an event log. 215 It must be noted that according to [GAL-GACH] a receiver MUST NOT 216 forward a GAL packet based on the GAL label as is normally the case 217 for MPLS packets. If the GAL appears at the bottom of the label 218 stack, it MUST be processed as described in the previous paragraph. 220 Note that there is no requirement for MPLS-TP devices to support IP 221 or OSI forwarding in the fast or slow paths. Thus, if a message is 222 received on the MCC or SCC and is not targeted to an address of the 223 receiving LSR, the LSR MAY discard the message as incorrectly 224 received. 226 3. Security Considerations 228 The G-ACh provides a virtual link between LSRs and might be used to 229 induce many forms of security attack. Protocols that operate over the 230 MCN or SCN are REQUIRED to include adequate security mechanisms and 231 implementations MUST allow operators to configure the use of those 232 mechanisms. 234 4. IANA Considerations 236 Channel Types for the Generic Associated Channel are allocated from 237 the IANA PW Associated Channel Type registry defined in [RFC4446] and 238 updated by [GAL-GACH]. 240 IANA is requested to allocate two further Channel Types as follows: 242 xx Management Communication Channel (MCC) 243 yy Signaling Communication Channel (SCC) 245 5. Normative References 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 250 [RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge 251 (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, 252 February 2006. 254 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 255 Emulation (PWE3)", RFC 4446, April 2006 . 257 [GAL-GACH] Vigoureux, M., Bocci, M., Ward, D., Swallow, G., and R. 258 Aggarwal, "MPLS Generic Associated Channel", 259 draft-ietf-mpls-tp-gach-gal, work in progress. 261 [ACH-TLV] Bryant, S., "Definition of ACH TLVs", draft-bryant-xxxx, 262 work in progress. 264 6. Informative References 266 [MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS 267 in Transport Networks", draft-ietf-mpls-tp-framework, work 268 in progress. 270 [G.7712] ITU-T Recommendation G.7712, "Architecture and 271 specification of data communication network", June 2008. 273 7. Acknowledgements 275 The editors wish to thank Pietro Grandi and Martin Vigoureux for 276 their contribution to this document. 278 8. Authors' Addresses 280 Dieter Beller 281 Alcatel-Lucent Germany 282 EMail: dieter.beller@alcatel-lucent.com 284 Adrian Farrel 285 Old Dog Consulting 286 EMail: adrian@olddog.co.uk 288 Full Copyright Statement 290 The IETF Trust takes no position regarding the validity or scope of 291 any Intellectual Property Rights or other rights that might be 292 claimed to pertain to the implementation or use of the technology 293 described in any IETF Document or the extent to which any license 294 under such rights might or might not be available; nor does it 295 represent that it has made any independent effort to identify any 296 such rights. 298 Copies of Intellectual Property disclosures made to the IETF 299 Secretariat and any assurances of licenses to be made available, or 300 the result of an attempt made to obtain a general license or 301 permission for the use of such proprietary rights by implementers or 302 users of this specification can be obtained from the IETF on-line IPR 303 repository at http://www.ietf.org/ipr 305 The IETF invites any interested party to bring to its attention any 306 copyrights, patents or patent applications, or other proprietary 307 rights that may cover technology that may be required to implement 308 any standard or specification contained in an IETF Document. Please 309 address the information to the IETF at ietf-ipr@ietf.org. 311 The definitive version of an IETF Document is that published by, or 312 under the auspices of, the IETF. Versions of IETF Documents that are 313 published by third parties, including those that are translated into 314 other languages, should not be considered to be definitive versions 315 of IETF Documents. The definitive version of these Legal Provisions 316 is that published by, or under the auspices of, the IETF. Versions of 317 these Legal Provisions that are published by third parties, including 318 those that are translated into other languages, should not be 319 considered to be definitive versions of these Legal Provisions. 321 For the avoidance of doubt, each Contributor to the IETF Standards 322 Process licenses each Contribution that he or she makes as part of 323 the IETF Standards Process to the IETF Trust pursuant to the 324 provisions of RFC 5378. No language to the contrary, or terms, 325 conditions or rights that differ from or are inconsistent with the 326 rights and licenses granted under RFC 5378, shall have any effect and 327 shall be null and void, whether published or posted by such 328 Contributor, or included with or in such Contribution. 330 Disclaimer of Validity 332 All IETF Documents and the information contained therein are provided 333 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 334 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 335 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 336 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 337 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 338 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 339 FOR A PARTICULAR PURPOSE. 341 Full Copyright Statement 343 Copyright (c) 2009 IETF Trust and the persons identified as the 344 document authors. All rights reserved. 346 This document is subject to BCP 78 and the IETF Trust's Legal 347 Provisions Relating to IETF Documents in effect on the date of 348 publication of this document (http://trustee.ietf.org/license-info). 349 Please review these documents carefully, as they describe your 350 rights and restrictions with respect to this document.