GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5718

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5718.txt · Last modified: 2010/01/07 17:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki