idnits 2.17.1 draft-ietf-mpls-tp-gach-dcn-06.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: September 19, 2009 Old Dog Consulting 5 Expires: March 19, 2010 7 An Inband Data Communication Network For the MPLS Transport Profile 9 draft-ietf-mpls-tp-gach-dcn-06.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 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 ACH is referred in this document as the G-ACh header. 83 The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in 84 [TP-REQ]. MPLS-TP is the application of MPLS to construct a packet 85 transport network. It constitutes a profile of MPLS that enables 86 operational models typical in transport networks, which includes 87 additional OAM, survivability and other maintenance functions not 88 previously supported by MPLS. 90 Label Switching Routers (LSRs) 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 nodes 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 nodes can communicate using 97 management plane or control plane protocols, channels must be 98 provided, and the only available mechanism is to use an MPLS label. 100 The G-ACh provides a suitable mechanism for this purpose, and this 101 document defines processes and procedures to allow the G-ACh to be 102 used to build a management communication network (MCN) and a 103 signaling communication network (SCN) together known as the data 104 communication network (DCN) [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 an MPLS-TP tunnel that traverses 122 another operator's domain (carrier's carrier scenario) 124 3. The G-ACh shall provide two independent channels: an MCC to build 125 the MCN and an SCC to build the SCN. The G-ACh packet header shall 126 indicate whether the packet is an MCC or an SCC packet in order to 127 forward it to the management or control plane application for 128 processing. This facilitates easy demultiplexing of control and 129 management traffic from the DCN and enables separate or 130 overlapping address spaces and duplicate protocol instances in the 131 management and control planes. 133 4. The channel separation mechanism shall not preclude the use of 134 separate rate limiters and traffic shaping functions for each 135 channel (MCC and SCC) ensuring that the flows do not exceed their 136 assigned traffic profiles. The rate limiters and traffic shapers 137 are outside the scope of the MCC and SCC definitions. 139 5. The G-ACh that carries the MCC and SCC shall be capable of 140 carrying different OSI layer 3 (network layer) PDUs. These shall 141 include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC 142 packet shall indicate which layer 3 PDU is contained in the 143 payload field of the packet such that the packet can be delivered 144 to the related layer 3 process within the management and control 145 plane application, respectively, for further processing. 147 6. The G-ACh is not required to provide specific security mechanisms. 148 However, the management or control plane protocols that operate 149 over the MCC or SCC are required to provide adequate security 150 mechanisms in order not to be susceptible to security attacks. 152 2. Procedures 154 Figure 1 depicts the format of an MCC/SCC packet that is sent on the 155 G-ACh. The Channel Type field indicates the function of the ACH 156 message so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC 157 message is prepended with an ACH with the Channel Type set to 158 indicate that the message is an MCC or SCC message. The ACH MUST NOT 159 include the ACH TLV Header [RFC5586] meaning that no ACH TLVs can be 160 included in the message. A two byte Protocol Identifier (PID) field 161 indicates the protocol type of the payload DCN message. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |0 0 0 1|Version| Reserved | Channel Type | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | PID | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 170 | MCC/SCC Message | 171 ~ ~ 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1: G-ACh MCC/SCC Packet 176 o The Channel Type field determines whether the message is an MCC or 177 an SCC message. See Section 5 for the codepoint assignments. 179 o The presence of the PID field is deduced from the Channel Type 180 value indicating MCC or SCC. The field contains an identifier of 181 the payload protocol using the PPP protocol identifiers [RFC1661], 182 [RFC3818]. 184 When the G-ACh sender receives an MCC message that is to be sent over 185 the MCC, the sender creates the G-ACh header, sets the Channel 186 Type field to MCC, fills in the PID to indicate the MCC layer 3 PDU 187 type,and prepends the MCC message with the G-ACh header. The same 188 procedure is applied when a control plane message is to be sent over 189 the SCC. In this case, the sender sets the Channel Type field to SCC. 191 If the G-ACh is associated with an MPLS section, the GAL is added to 192 the message as defined in [RFC5586]. The TTL field MUST be set to 1, 193 and the S-bit of the GAL MUST be set to 1. 195 If the G-ACh is associated with an LSP, the GAL is added to the 196 packet and the LSP label is pushed on top of the GAL as defined in 197 [RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit 198 of the GAL MUST be set to 1. 200 Note that packet processing for DCN packets in the G-ACh is, in 201 common with all G-ACh MPLS packets, subject to the normal processing 202 of the Traffic Class (TC) field of the MPLS header. This could be 203 used to enable prioritisation of different DCN packets. 205 The DCN channel MUST NOT be used to transport user traffic and SHALL 206 only be used to carry management or control plane messages. 207 Procedures that ensure this (such as deep packet inspection) are 208 outside the scope of this specification. 210 When a receiver has received a packet on the G-ACh with the ACH 211 Channel Type set to MCC or SCC, it SHALL look at the PID field. If 212 the PID value is known by the receiver it delivers the the MCC/SCC 213 message to the appropriate processing entity. If the PID value is 214 unknown, the receiver SHALL silently discard the received packet, 215 MAY increment a counter that records discarded or errored messages, 216 and MAY log an event. 218 It must be noted that according to [RFC5586] a receiver MUST NOT 219 forward a GAL packet based on the GAL label as is normally the case 220 for MPLS packets. If the GAL appears at the bottom of the label 221 stack, it MUST be processed as described in the previous paragraph. 223 Note that there is no requirement for MPLS-TP devices to support IP 224 or OSI forwarding in the fast (forwarding) path. Thus, if a message 225 is received on the MCC or SCC and is not targeted to an address of 226 the receiving MPLS-TP node the packet might not be forwarded in the 227 fast path. A node MAY apply layer 3 forwarding procedures in the slow 228 or fast path and MAY discard or reject the message using the layer 3 229 protocol if it is unable to forward it. Thus, protocols making use of 230 the DCN should make no assumptions about the forwarding capabilities 231 unless they are determined a priori or through the use of a routing 232 protocol. Furthermore it is important that user data (i.e., data 233 traffic) is not routed through the DCN as this would potentially 234 cause the traffic to be lost or delayed, and might significantly 235 congest the DCN. 237 2.1. Pseudowire Setup 239 Provider Edge nodes may wish to set up PWs using a signaling protocol 240 that uses remote adjacencies (such as LDP [RFC5036]). In the absence 241 of an IP-based control plane network, these PEs MUST first set up an 242 LSP tunnel across the MPLS-TP network. This tunnel can be used both 243 to carry the PW once it has been set up and to provide a G-ACh based 244 DCN for control plane communications between the PEs. 246 3. Applicability 248 The DCN is intended to provide connectivity between management 249 stations and network nodes, and between pairs of network nodes, for 250 the purpose of exchanging management plane and control plane 251 messages. 253 Appendix A of [NM-REQ] describes how Control Channels (CCh) that are 254 the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in- 255 fiber and out-of-band, or in-band with respect to the user data 256 carried by the MPLS-TP network. The Appendix also explains how the 257 DCN can be constructed from a mix of different types of links and 258 how routing and forwarding can be used within the DCN to facilitate 259 multi-hop delivery of management and control plane messages. 261 The G-ACh used as described in this document allows the creation of 262 a "data channel associated CCh" (type 6 in Appendix A of [NM-REQ]) 263 and an "in-band CCh" (type 7 in Appendix A of [NM-REQ]). In the 264 former case, the G-ACh is associated with an MPLS-TP section. In the 265 latter case, the G-ACh is associated with an MPLS-TP LSP or PW and 266 may span one or more hops in the MPLS-TP network. 268 There is no need to create a CCh for every LSP between a pair of 269 Indeed, where the nodes are physically adjacent, the G-ACh associated 270 with the MPLS-TP section would normally be used. Where nodes are 271 virtually adjacent (that is, connected by LSP tunnels), one or two of 272 the LSPs might be selected to provide the CCh and a back-up CCh. 274 4. Security Considerations 276 The G-ACh provides a virtual link between MPLS-TP nodes and might be 277 used to induce many forms of security attack. Protocols that operate 278 over the MCN or SCN are REQUIRED to include adequate security 279 mechanisms and implementations MUST allow operators to configure the 280 use of those mechanisms. 282 5. IANA Considerations 284 Channel Types for the Generic Associated Channel are allocated from 285 the IANA PW Associated Channel Type registry defined in [RFC4446] and 286 updated by [RFC5586]. 288 IANA is requested to allocate two further Channel Types as follows: 289 xx Management Communication Channel (MCC) 290 yy Signaling Communication Channel (SCC) 292 6. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge 298 (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, 299 February 2006. 301 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 302 Emulation (PWE3)", RFC 4446, April 2006 . 304 [RFC5586] Bocci, M., Vigoureux, M., and Bryant, S., "MPLS Generic 305 Associated Channel", RFC 5586, June 2009. 307 7. Informative References 309 [MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS 310 in Transport Networks", draft-ietf-mpls-tp-framework, work 311 in progress. 313 [TP-REQ] B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., 314 N. Sprecher, S. Ueno, "MPLS-TP Requirements", 315 draft-ietf-mpls-tp-requirements, work in progress. 317 [NM-REQ] Lam, H.-K., Mansfield, S., and Gray, E., "MPLS TP Network 318 Management Requirements", draft-ietf-mpls-tp-nm-req, work 319 in progress. 321 [G.7712] ITU-T Recommendation G.7712, "Architecture and 322 specification of data communication network", June 2008. 324 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 325 RFC 1661, July 1994. 327 [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point 328 Protocol (PPP)", BCP 88, RFC 3818, June 2004. 330 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 331 Specification", RFC 5036, October 2007. 333 8. Acknowledgements 335 The editors wish to thank Pietro Grandi, Martin Vigoureux, Kam Lam, 336 Ben Niven-Jenkins, Francesco Fondelli, Walter Rothkegel, Shahram 337 Davari, Liu Guoman, and Alexander Vainshtein for their contribution 338 to this document, and the MEAD team for thorough review. 340 Study Group 15 of the ITU-T provided the basis for the requirements 341 text in Section 1.1. 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 Copyright (c) 2009 IETF Trust and the persons identified as the 356 document authors. All rights reserved. 358 This document is subject to BCP 78 and the IETF Trust's Legal 359 Provisions Relating to IETF Documents in effect on the date of 360 publication of this document (http://trustee.ietf.org/license-info). 361 Please review these documents carefully, as they describe your rights 362 and restrictions with respect to this document.