summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5718.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5718.txt')
-rw-r--r--doc/rfc/rfc5718.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc5718.txt b/doc/rfc/rfc5718.txt
new file mode 100644
index 0000000..c8fc146
--- /dev/null
+++ b/doc/rfc/rfc5718.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Beller
+Request for Comments: 5718 Alcatel-Lucent
+Category: Standards Track A. Farrel
+ISSN: 2070-1721 Old Dog Consulting
+ January 2010
+
+
+ An In-Band Data Communication Network For the MPLS Transport Profile
+
+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 that is
+ 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
+ for delivery to the management or signaling/routing control plane
+ components on an MPLS-TP node.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5718.
+
+
+
+
+
+
+Beller & Farrel Standards Track [Page 1]
+
+RFC 5718 DCN for MPLS Transport Profile January 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 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
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+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 Operations, Administration, and Maintenance
+ (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 ACH is
+ referred to in this document as the G-ACh header.
+
+ The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in
+ [RFC5654]. 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
+
+
+
+
+Beller & Farrel Standards Track [Page 2]
+
+RFC 5718 DCN for MPLS Transport Profile January 2010
+
+
+ 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.
+
+ 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].
+
+ 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.
+
+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 (the 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. This facilitates easy demultiplexing of control
+ and management traffic from the DCN, and enables separate or
+ overlapping address spaces and duplicate protocol instances in the
+ management and control planes.
+
+ 4. The channel-separation mechanism shall not preclude 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.
+
+
+
+
+
+Beller & Farrel Standards Track [Page 3]
+
+RFC 5718 DCN for MPLS Transport Profile January 2010
+
+
+ 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 to not be susceptible to security attacks.
+
+1.2. 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].
+
+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 and 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 NOT include the ACH TLV Header [RFC5586], meaning that no ACH
+ TLVs can be included in the message. A two-byte Protocol
+ Identifier (PID) field indicates the protocol type of the payload
+ DCN message.
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PID | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ | 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.
+
+
+
+
+Beller & Farrel Standards Track [Page 4]
+
+RFC 5718 DCN for MPLS Transport Profile January 2010
+
+
+ o The presence of the PID field is deduced from the Channel Type
+ value indicating MCC or SCC. The field contains an identifier of
+ the payload protocol using the PPP protocol identifiers ([RFC1661],
+ [RFC3818]).
+
+ When the G-ACh sender receives an MCC message that is to be sent over
+ the MCC, the sender creates the G-ACh header, sets the Channel Type
+ field to MCC, fills in the PID to indicate the MCC layer 3 PDU type,
+ 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 Generic
+ Associated Channel Label (GAL) is added to the message as defined in
+ [RFC5586]. The Time to Live (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.
+
+ Note that packet processing for DCN packets in the G-ACh is, in
+ common with all G-ACh MPLS packets, subject to the normal processing
+ of the Traffic Class (TC) field of the MPLS header. This could be
+ used to enable prioritization of different DCN packets.
+
+ 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. If
+ the PID value is known by the receiver, it delivers 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.
+
+
+
+
+
+
+Beller & Farrel Standards Track [Page 5]
+
+RFC 5718 DCN for MPLS Transport Profile January 2010
+
+
+ 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 packet might not be forwarded in the
+ fast path. A node MAY apply layer 3 forwarding procedures in the
+ slow or fast path and MAY discard or reject the message using the
+ layer 3 protocol if it is unable to forward it. Thus, protocols
+ making use of the DCN should make no assumptions about the forwarding
+ capabilities unless they are determined a priori or through the use
+ of a routing protocol. Furthermore, it is important that user data
+ (i.e., data traffic) is not routed through the DCN, as this would
+ potentially cause the traffic to be lost or delayed and might
+ significantly congest the DCN.
+
+2.1. Pseudowire Setup
+
+ Provider Edge nodes (PEs) may wish to set up PWs using a signaling
+ 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 intended 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. That 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.
+
+
+
+
+
+
+Beller & Farrel Standards Track [Page 6]
+
+RFC 5718 DCN for MPLS Transport Profile January 2010
+
+
+ There is no need to create a CCh for every LSP between a pair of
+ MPLS-TP nodes. Indeed, where the nodes are physically adjacent, the
+ G-ACh associated with the MPLS-TP section would normally be used.
+ Where nodes are virtually adjacent (that is, connected by LSP
+ tunnels), one or two of the LSPs might be selected to provide the CCh
+ and a back-up CCh.
+
+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. The MPLS data plane
+ does not include any security mechanisms of its own; therefore, it is
+ important that protocols using the DCN apply their own security.
+ 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 has allocated two further Channel Types as follows:
+ 0x0001 Management Communication Channel (MCC)
+ 0x0002 Signaling Communication Channel (SCC)
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
+ "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)", BCP 116, RFC 4446, April 2006.
+
+ [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
+ "MPLS Generic Associated Channel", RFC 5586, June 2009.
+
+6.2. Informative References
+
+ [G.7712] ITU-T Recommendation G.7712, "Architecture and
+ specification of data communication network", June 2008.
+
+
+
+Beller & Farrel Standards Track [Page 7]
+
+RFC 5718 DCN for MPLS Transport Profile January 2010
+
+
+ [MPLS-TP] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A
+ Framework for MPLS in Transport Networks", Work in
+ Progress, October 2009.
+
+ [NM-REQ] Lam, K. and S. Mansfield, "MPLS TP Network Management
+ Requirements", Work in Progress, October 2009.
+
+ [RFC1661] Simpson, W., Ed., "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., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+ "LDP Specification", RFC 5036, October 2007.
+
+ [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
+ Sprecher, N., and S. Ueno, "Requirements of an MPLS
+ Transport Profile", RFC 5654, September 2009.
+
+7. Acknowledgements
+
+ The editors wish to thank Pietro Grandi, Martin Vigoureux, Kam Lam,
+ Ben Niven-Jenkins, Francesco Fondelli, Walter Rothkegel, Shahram
+ Davari, Liu Guoman, and Alexander Vainshtein for their contribution
+ to this document, and the MEAD team for thorough review.
+
+ Study Group 15 of the ITU-T provided the basis for the requirements
+ text in Section 1.1.
+
+Authors' Addresses
+
+ Dieter Beller
+ Alcatel-Lucent Germany
+ EMail: dieter.beller@alcatel-lucent.com
+
+
+ Adrian Farrel
+ Old Dog Consulting
+ EMail: adrian@olddog.co.uk
+
+
+
+
+
+
+
+
+
+
+
+Beller & Farrel Standards Track [Page 8]
+