doc: Add RFC documents

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]
+