idnits 2.17.1 draft-ietf-mpls-tp-gach-dcn-00.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: March 25, 2009 Old Dog Consulting 5 Expires: September 25, 2009 7 An Inband Data Communication Network For the MPLS Transport Profile 9 draft-ietf-mpls-tp-gach-dcn-00.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 A Generic Associated Channel (G-ACH) has been defined as an extension 35 of the pseudowire Associated Channel Header (ACH) to enable the 36 realization of a control/communication channel associated with 37 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), 38 MPLS pseudowires (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). 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 ACH is generalized for use on any Multiprotocol Label Switching 73 (MPLS) Label Switching Path (LSP) in [GAL-GACH]. The generalized 74 concept is referred to as the Generic Associated Channel (G-ACH) and 75 is intended to create a control/communication channel associated with 76 the LSP that can be used to carry packets used for OAM and similar 77 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 PW Associated Channel Type field of the G-ACH 81 and a registry of values is maintained by IANA. 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 over 152 the G-ACH. To send an MCC/SCC packet on the G-ACH, the MCC/SCC packet 153 is prepended with the extended G-ACH header. This extended G-ACH 154 header is composed of the G-ACH header as defined in [GAL-GACH] and 155 is extended by four bytes providing an 8-bit protocol identifier 156 (PID) field. The remaining 24 bits of the header extension are 157 reserved. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 |0 0 0 1|Version|A| Reserved | Channel Type | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Reserved | PID | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | MCC/SCC Packet | 167 ~ ~ 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 1: MCC/SCC Packet with Associated Channel Header 172 o The Channel Type field determines whether the message is an MCC or 173 an SCC message. See Section 4 for the codepoint assignments. 175 o The PID field indicates the PDU type of the MCC/SCC message 177 The following PID values are defined: 179 0x00 IPv4 180 0x01 IPv6 181 0x02 OSI 182 0x03-0xFF Reserved 184 Editor Note: This approach may be changed to use the G-ACH Protocol 185 Identifier TLV if that work is progressed. 187 If the PID is OSI, the first octet of the OSI PDU header (Network 188 Layer Protocol Identifier) as defined in [ISO8473] indicates the 189 network layer PDU which can be CLNP (0x81), ES-IS (0x82), or IS-IS 190 (0x83) as specified in [ISO9577]. 192 When the G-ACH sender receives an MCC message from the management 193 application that is supposed to be sent over the MCC, the sender 194 creates the extended the G-ACH header depending on the MCC layer 3 195 PDU, sets the Channel Type field to MCC, and prepends the MCC message 196 with the extended G-ACH header. The same procedure is applied when a 197 control plane message is supposed to be sent over the SCC. In this 198 case, the sender sets the Channel Type field to SCC. 200 If the MPLS section G-ACH is used, the GAL is added to the packet as 201 defined in [GAL-GACH], i.e., the TTL field SHOULD be set to 1, and 202 the S-bit of the GAL MUST be set to 1. 204 If the G-ACH is associated with an LSP, the GAL is added to the 205 packet and the LSP label is pushed on top of the GAL as defined in 206 [GAL-GACH], i.e., the TTL field of the GAL SHOULD be set to 1, and 207 the S-bit of the GAL MUST be set to 1. 209 It should be noted that the G-ACH MUST NOT be used to carry user data 210 and SHALL only be used to carry management or control plane messages. 211 Procedures that ensure this such as e.g. deep packet inspection are 212 outside the scope of this specification. 214 When a receiver has received a G-ACH packet with the G-ACH Channel 215 Type set to MCC or SCC, it SHALL look at the PID field of the 216 extended G-ACH header. If the PID value is known by the receiver it 217 SHALL deliver the entire packet including the MCC/SCC message to the 218 appropriate processing entity. If the PID value is unknown, the 219 receiver SHALL silently discard the received Packet and MAY increment 220 a counter that counts discarded packets. 222 It must be noted that a receiver MUST NOT forward a GAL packet based 223 on the GAL label as is normally the case for MPLS packets. If the GAL 224 appears at the bottom of the label stack, it MUST be processed as 225 described in the previous paragraph. 227 Note that there is no requirement for MPLS-TP devices to support IP 228 or OSI forwarding in the fast or slow paths. Thus, if a message is 229 received on the MCC or SCC and is not targeted to an address of the 230 receiving LSR, the LSR MAY discard the message as incorrectly 231 received. 233 3. Security Considerations 235 The G-ACH provides a virtual link between LSRs and might be used to 236 induce many forms of security attack. Protocols that operate over the 237 MCN or SCN are REQUIRED to include adequate security mechanisms and 238 implementations MUST allow operators to configure the use of those 239 mechanisms. 241 4. IANA Considerations 243 Channel Types for the Generic Associated Channel are allocated from 244 the IANA PW Associated Channel Type registry defined in [RFC4446] and 245 updated by [GAL-GACH]. 247 IANA is requested to allocate two further Channel Types as follows: 249 xx Management Communication Channel (MCC) 250 yy Signaling Communication Channel (SCC) 252 5. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge 258 (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, 259 February 2006. 261 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 262 Emulation (PWE3)", RFC 4446, April 2006 . 264 [GAL-GACH] Vigoureux, M., Bocci, M., Ward, D., Swallow, G., and R. 265 Aggarwal, "MPLS Generic Associated Channel", 266 draft-ietf-mpls-tp-gach-gal, work in progress. 268 6. Informative References 270 [MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS 271 in Transport Networks", draft-ietf-mpls-tp-framework, work 272 in progress. 274 [G.7712] ITU-T Recommendation G.7712, "Architecture and 275 specification of data communication network", June 2008. 277 [ISO8473] ISO/IEC 8473-1, "Protocol for providing the 278 connectionless-mode network service: Protocol 279 specification - Part 1: ISO/IEC JTC 1/SC", 1998-11-01. 281 [ISO9577] ISO/IEC TR 9577, "Protocol identification in the network 282 layer ISO/IEC JTC 1/SC 6", 1999-12-15. 284 7. Acknowledgements 286 The editors wish to thank Pietro Grandi and Martin Vigoureux for 287 their contribution to this document. 289 8. Authors' Addresses 291 Dieter Beller 292 Alcatel-Lucent Germany 293 EMail: dieter.beller@alcatel-lucent.com 295 Adrian Farrel 296 Old Dog Consulting 297 EMail: adrian@olddog.co.uk 299 Full Copyright Statement 301 The IETF Trust takes no position regarding the validity or scope of 302 any Intellectual Property Rights or other rights that might be 303 claimed to pertain to the implementation or use of the technology 304 described in any IETF Document or the extent to which any license 305 under such rights might or might not be available; nor does it 306 represent that it has made any independent effort to identify any 307 such rights. 309 Copies of Intellectual Property disclosures made to the IETF 310 Secretariat and any assurances of licenses to be made available, or 311 the result of an attempt made to obtain a general license or 312 permission for the use of such proprietary rights by implementers or 313 users of this specification can be obtained from the IETF on-line IPR 314 repository at http://www.ietf.org/ipr 316 The IETF invites any interested party to bring to its attention any 317 copyrights, patents or patent applications, or other proprietary 318 rights that may cover technology that may be required to implement 319 any standard or specification contained in an IETF Document. Please 320 address the information to the IETF at ietf-ipr@ietf.org. 322 The definitive version of an IETF Document is that published by, or 323 under the auspices of, the IETF. Versions of IETF Documents that are 324 published by third parties, including those that are translated into 325 other languages, should not be considered to be definitive versions 326 of IETF Documents. The definitive version of these Legal Provisions 327 is that published by, or under the auspices of, the IETF. Versions of 328 these Legal Provisions that are published by third parties, including 329 those that are translated into other languages, should not be 330 considered to be definitive versions of these Legal Provisions. 332 For the avoidance of doubt, each Contributor to the IETF Standards 333 Process licenses each Contribution that he or she makes as part of 334 the IETF Standards Process to the IETF Trust pursuant to the 335 provisions of RFC 5378. No language to the contrary, or terms, 336 conditions or rights that differ from or are inconsistent with the 337 rights and licenses granted under RFC 5378, shall have any effect and 338 shall be null and void, whether published or posted by such 339 Contributor, or included with or in such Contribution. 341 Disclaimer of Validity 343 All IETF Documents and the information contained therein are provided 344 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 345 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 346 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 347 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 348 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 349 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 350 FOR A PARTICULAR PURPOSE. 352 Full Copyright Statement 354 Copyright (c) 2009 IETF Trust and the persons identified as the 355 document authors. All rights reserved. 357 This document is subject to BCP 78 and the IETF Trust's Legal 358 Provisions Relating to IETF Documents in effect on the date of 359 publication of this document (http://trustee.ietf.org/license-info). 360 Please review these documents carefully, as they describe your 361 rights and restrictions with respect to this document.