[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-beller-mpls-tp-gach-dcn) 00 01 02 03 04 05 06 RFC 5718

Networking Working Group                                       D. Beller
Internet-Draft                                            Alcatel-Lucent
Intended Status: Standards Track                               A. Farrel
Created: May 13, 2009                                 Old Dog Consulting
Expires: November 13, 2009

   An Inband Data Communication Network For the MPLS Transport Profile

                  draft-ietf-mpls-tp-gach-dcn-02.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-02.txt                              May 2009


   for delivery to the management or signaling/routing control plane
   components on a label switching router (LSR).

   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 [GAL-GACH] 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 LSRs 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 LSRs 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-02.txt                              May 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 a MPLS-TP tunnel that traverses another
         operator's domain (carrier's carrier scenario)

   3. The G-ACh shall provide two independent channels: a MCC to build
      the MCN and a SCC to build the SCN. The G-ACh packet header shall
      indicate whether the packet is a 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 profile. The rate limiter and traffic shaper are outside
      the scope of the MCC and SCC definition.

   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 forwarded
      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-02.txt                              May 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 a 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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      ACH Protocol ID TLV                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                     zero or more other ACH TLVs               ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         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 4 for the codepoint assignments.

   o The ACH Protocol ID TLV identifies the PDU type of the MCC/SCC
     message. The ACH Protocol ID TLV is defined in [ACH-TLV] and uses
     the PPP protocol identifiers to distinguish different protocols
     [RFC1661].

   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 [GAL-GACH]. The TTL field MUST be set to 1,
   and the S-bit of the GAL MUST be set to 1.



Beller and Farrel                                               [Page 4]


draft-ietf-mpls-tp-gach-dcn-02.txt                              May 2009


   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
   [GAL-GACH]. 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 [GAL-GACH] 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 or slow paths. Thus, if a message is
   received on the MCC or SCC and is not targeted to an address of the
   receiving LSR, the LSR MAY discard the message as incorrectly
   received using whatever mechanisms are necessary according to layer 3
   protocol concerned.

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 t`he PEs.

   Note that messages delivered on the G-ACh MUST NOT be forwarded based
   on their payload (for example, IP, CLNS, etc).






Beller and Farrel                                               [Page 5]


draft-ietf-mpls-tp-gach-dcn-02.txt                              May 2009


3. Security Considerations

   The G-ACh provides a virtual link between LSRs 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.

4. 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 [GAL-GACH].

   IANA is requested to allocate two further Channel Types as follows:
     xx  Management Communication Channel (MCC)
     yy  Signaling Communication Channel (SCC)

5. 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 .

   [GAL-GACH] Vigoureux, M., Bocci, M., Ward, D., Swallow, G., and R.
              Aggarwal, "MPLS Generic Associated Channel",
              draft-ietf-mpls-tp-gach-gal, work in progress.

   [ACH-TLV]  Bryant, S., "Definition of ACH TLVs", draft-bryant-xxxx,
              work in progress.

6. 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.



Beller and Farrel                                               [Page 6]


draft-ietf-mpls-tp-gach-dcn-02.txt                              May 2009


   [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.

   [RFC5036]  Andersson, L., Minei, I., and Thomas, B., "LDP
              Specification", RFC 5036, October 2007.

7. Acknowledgements

   The editors wish to thank Pietro Grandi, Martin Vigoureux, and Kam
   Lam for their contribution to this document.

8. 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.




Beller and Farrel                                               [Page 7]


draft-ietf-mpls-tp-gach-dcn-02.txt                              May 2009


   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.

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


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/