Networking Working Group D. Beller Internet-Draft Alcatel-Lucent Intended Status: Standards Track A. Farrel Created: August 14, 2009 Old Dog Consulting Expires: February 14, 2010 An Inband Data Communication Network For the MPLS Transport Profile draft-ietf-mpls-tp-gach-dcn-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices. The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier grade packet transport network based on MPLS packet switching technology. This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed Beller and Farrel [Page 1]
draft-ietf-mpls-tp-gach-dcn-04.txt August 2009 for delivery to the management or signaling/routing control plane components on an MPLS-TP node. It should be noted that the use of the G-ACh to provide connectivity for the DCN is intended for use only where the MPLS-TP network is not capable of encapsulating or delivering native DCN messages. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 1. Introduction The associated channel header (ACH) is specified in [RFC4385]. It is a packet header format for use on pseudowires (PWs) in order to identify packets used for OAM and similar functions. The use of the ACH is generalized in [RFC5586] and can be applied on any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP). This is referred to as the Generic Associated Channel (G-ACh) and is intended to create a control/management communication channel associated with the LSP that can be used to carry packets used for OAM and similar functions (e.g., control/management plane messages). The purpose of a packet carried on the G-ACh is indicated by the value carried by the Channel Type field of the ACH and a registry of values is maintained by IANA ([RFC4446] and [RFC4385]). The combination of the ACH and the ACH TLVs that may be appended to the ACH is referred in this document as the G-ACh header. The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in [TP-REQ]. MPLS-TP is the application of MPLS to construct a packet transport network. It constitutes a profile of MPLS that enables operational models typical in transport networks, which includes additional OAM, survivability and other maintenance functions not previously supported by MPLS. Label Switching Routers (LSRs) in MPLS networks may be operated using management protocols or control plane protocols. Messaging in these protocols is normally achieved using IP packets exchanged over IP- capable interfaces. However, some nodes in MPLS-TP networks may be constructed without support for direct IP encapsulation on their line-side interfaces, and without access to an out-of-fiber data communication network. In order that such nodes can communicate using management plane or control plane protocols, channels must be provided, and the only available mechanism is to use an MPLS label. Beller and Farrel [Page 2]
draft-ietf-mpls-tp-gach-dcn-04.txt August 2009 The G-ACh provides a suitable mechanism for this purpose, and this document defines processes and procedures to allow the G-ACh to be used to build a management communication network (MCN) and a signaling communication network (SCN) together known as the data communication network (DCN) [G.7712]. 1.1. Requirements The requirements presented in this section are based on those communicated to the IETF by the ITU-T. 1. A packet encapsulation mechanism must be provided to support the transport of MCN and SCN packets over the G-ACh. 2. The G-ACh carrying the MCN and SCN packets shall support the following application scenarios: a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when the server layer does not provide a Management Communication Channel (MCC) or a Signalling Communication Channel (SCC)). b. The G-ACh is carried by an MPLS-TP tunnel that traverses another operator's domain (carrier's carrier scenario) 3. The G-ACh shall provide two independent channels: an MCC to build the MCN and an SCC to build the SCN. The G-ACh packet header shall indicate whether the packet is an MCC or an SCC packet in order to forward it to the management or control plane application for processing. 4. The channel separation mechanism shall allow the use of separate rate limiters and traffic shaping functions for each channel (MCC and SCC) ensuring that the flows do not exceed their assigned traffic profiles. The rate limiters and traffic shapers are outside the scope of the MCC and SCC definitions. 5. The G-ACh that carries the MCC and SCC shall be capable of carrying different OSI layer 3 (network layer) PDUs. These shall include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC packet shall indicate which layer 3 PDU is contained in the payload field of the packet such that the packet can be delivered to the related layer 3 process within the management and control plane application, respectively, for further processing. 6. The G-ACh is not required to provide specific security mechanisms. However, the management or control plane protocols that operate over the MCC or SCC are required to provide adequate security mechanisms in order not to be susceptible to security attacks. Beller and Farrel [Page 3]
draft-ietf-mpls-tp-gach-dcn-04.txt August 2009 2. Procedures Figure 1 depicts the format of an MCC/SCC packet that is sent on the G-ACh. The Channel Type field indicates the function of the ACH message so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC message is prepended with an ACH with the Channel Type set to indicate that the message is an MCC or SCC message. The ACH MUST include the ACH Protocol ID TLV [ACH-TLV] to identify the protocol type of the MCC or SCC message, and MAY include further ACH TLVs. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ zero or more ACH TLVs ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH Protocol ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MCC/SCC Message | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: G-ACh MCC/SCC Packet o The Channel Type field determines whether the message is an MCC or an SCC message. See Section 5 for the codepoint assignments. o No other ACH TLVs (except the ACH protocol ID TLV - see below) has been identified for use on a DCN message. If a message is received carrying an ACH TLV that is not understood in the context of a DCN message, the ACH TLV SHOULD be silently ignored and processing of the message SHOULD continue. o The ACH Protocol ID TLV identifies the PDU type of the MCC/SCC message. The ACH MUST be present in a DCN message and MUST be placed last in the sequence of ACh TLVs so that it comes immediately before the MCC/SCC message. Note that this means that the PID field of the TLV is immediately adjacent to the message iteslf. The ACH Protocol ID TLV is defined in [ACH-TLV] and uses the PPP protocol identifiers to distinguish different protocols [RFC1661], [RFC3818]. Beller and Farrel [Page 4]
draft-ietf-mpls-tp-gach-dcn-04.txt August 2009 When the G-ACh sender receives an MCC message that is to be sent over the MCC, the sender creates the G-ACh header, provides an ACH Protocol ID TLV indicating the MCC layer 3 PDU type, sets the Channel Type field to MCC, and prepends the MCC message with the G-ACh header. The same procedure is applied when a control plane message is to be sent over the SCC. In this case, the sender sets the Channel Type field to SCC. If the G-ACh is associated with an MPLS section, the GAL is added to the message as defined in [RFC5586]. The TTL field MUST be set to 1, and the S-bit of the GAL MUST be set to 1. If the G-ACh is associated with an LSP, the GAL is added to the packet and the LSP label is pushed on top of the GAL as defined in [RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit of the GAL MUST be set to 1. The DCN channel MUST NOT be used to transport user traffic and SHALL only be used to carry management or control plane messages. Procedures that ensure this (such as deep packet inspection) are outside the scope of this specification. When a receiver has received a packet on the G-ACh with the ACH Channel Type set to MCC or SCC, it SHALL look at the PID field carried in the ACH Protocol ID TLV. If the TLV is absent, the message SHALL be silently discarded, although a local system MAY increment a counter that records discarded or errored packets, and MAY log an event. If the PID value is known by the receiver it SHALL deliver the entire packet including the MCC/SCC message to the appropriate processing entity. If the PID value is unknown, the receiver SHALL silently discard the received packet, MAY increment a counter that records discarded or errored messages, and MAY log an event. It must be noted that according to [RFC5586] a receiver MUST NOT forward a GAL packet based on the GAL label as is normally the case for MPLS packets. If the GAL appears at the bottom of the label stack, it MUST be processed as described in the previous paragraph. Note that there is no requirement for MPLS-TP devices to support IP or OSI forwarding in the fast (forwarding) path. Thus, if a message is received on the MCC or SCC and is not targeted to an address of the receiving MPLS-TP node, the node MUST NOT forward the packet in the fast path. The node SHOULD apply layer 3 forwarding procedures in the slow path and MAY discard or rehect the message using the layer 3 protocol if it is unable to forward it. Beller and Farrel [Page 5]
draft-ietf-mpls-tp-gach-dcn-04.txt August 2009 2.1. Pseudowire Setup Provider Edge nodes may wish to set up PWs using a singaling protocol that uses remote adjacencies (such as LDP [RFC5036]). In the absence of an IP-based control plane network, these PEs MUST first set up an LSP tunnel across the MPLS-TP network. This tunnel can be used both to carry the PW once it has been set up and to provide a G-ACh based DCN for control plane communications between the PEs. 3. Applicability The DCN is intented to provide connectivity between management stations and network nodes, and between pairs of network nodes, for the purpose of exchanging management plane and control plane messages. Appendix A of [NM-REQ] describes how Control Channels (CCh) that are the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in- fiber and out-of-band, or in-band with respect to the user data carried by the MPLS-TP network. The Appendix also explains how the DCN can be constructed from a mix of different types of links and how routing and forwarding can be used within the DCN to facilitate multi-hop delivery of management and control plane messages. The G-ACh used as described in this document allows the creation of a "data channel associated CCh" (type 6 in Appendix A of [NM-REQ]) and an "in-band CCh" (type 7 in Appendix A of [NM-REQ]). In the former case, the G-ACh is associated with an MPLS-TP section. In the latter case, the G-ACh is associated with an MPLS-TP LSP or PW and may span one or more hops in the MPLS-TP network. 4. Security Considerations The G-ACh provides a virtual link between MPLS-TP nodes and might be used to induce many forms of security attack. Protocols that operate over the MCN or SCN are REQUIRED to include adequate security mechanisms and implementations MUST allow operators to configure the use of those mechanisms. 5. IANA Considerations Channel Types for the Generic Associated Channel are allocated from the IANA PW Associated Channel Type registry defined in [RFC4446] and updated by [RFC5586]. IANA is requested to allocate two further Channel Types as follows: xx Management Communication Channel (MCC) yy Signaling Communication Channel (SCC) Beller and Farrel [Page 6]
draft-ietf-mpls-tp-gach-dcn-04.txt August 2009 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", RFC 4446, April 2006 . [RFC5586] Bocci, M., Vigoureux, M., and Bryant, S., "MPLS Generic Associated Channel", RFC 5586, June 2009. [ACH-TLV] Bryant, S., et al., "Definition of ACH TLV Structure", draft-bryant-mpls-tp-ach-tlv, work in progress. 7. Informative References [MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework, work in progress. [TP-REQ] B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., N. Sprecher, S. Ueno, "MPLS-TP Requirements", draft-ietf-mpls-tp-requirements, work in progress. [NM-REQ] Lam, H.-K., Mansfield, S., and Gray, E., "MPLS TP Network Management Requirements", draft-ietf-mpls-tp-nm-req, work in progress. [G.7712] ITU-T Recommendation G.7712, "Architecture and specification of data communication network", June 2008. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", BCP 88, RFC 3818, June 2004. [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP Specification", RFC 5036, October 2007. Beller and Farrel [Page 7]
draft-ietf-mpls-tp-gach-dcn-04.txt August 2009 8. Acknowledgements The editors wish to thank Pietro Grandi, Martin Vigoureux, and Kam Lam for their contribution to this document, and the MEAD team for thorough review. 9. Authors' Addresses Dieter Beller Alcatel-Lucent Germany EMail: dieter.beller@alcatel-lucent.com Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Full Copyright Statement The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. Beller and Farrel [Page 8]
draft-ietf-mpls-tp-gach-dcn-04.txt August 2009 For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Beller and Farrel [Page 9]
