MPLS Working Group                                         M. Bocci, Ed.
Internet-Draft                                         M. Vigoureux, Ed.
Updates: 3032, 4385, 5085                                 Alcatel-Lucent
(if approved)                                                 G. Swallow
Intended status: Standards Track                                 D. Ward
Expires: July 10, August 27, 2009                                       S. Bryant
                                                                   Cisco
                                                             R. Aggarwal
                                                        Juniper Networks
                                                         January 6,
                                                       February 23, 2009

                 MPLS Generic Associated Channel
                     draft-ietf-mpls-tp-gach-gal-01 header
                     draft-ietf-mpls-tp-gach-gal-02

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.

   This Internet-Draft will expire on July 10, August 27, 2009.

Copyright Notice

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

Abstract

   This document generalises the applicability of the pseudowire (PW)
   Associated Channel Header (ACH), enabling the realization of a
   control channel associated to MPLS Label Switched Paths (LSP), MPLS
   pseudowires (PW) (LSPs) and
   MPLS Sections. Sections in addition to MPLS pseudowires.  In order to identify
   the presence of this Associated Channel Header in the Generic ACH (G-ACH), label stack,
   this document also assigns of one of the reserved MPLS label values to
   the 'Generic Generic Associated channel header Label (GAL)', (GAL), to be used as a label
   based exception mechanism.

Requirements Language

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Contributing Authors . . . . . . . . . . . . . . . . . . .  5
     1.2.  Objectives . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5  6
   2.  Generic Associated Channel Header  . . . . . . . . . . . . . .  6
     2.1.  Definition . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Allocation of Channel Types  . . . . . . . . . . . . . . .  7
   3.  ACH TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  ACH TLV Payload Structure  . . . . . . . . . . . . . . . .  8
     3.2.  ACH TLV Header . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  ACH TLV Object . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Generalised Exception Mechanism  . . . . . . . . . . . . . . .  7
     3.1.  9
     4.1.  Relationship with Existing MPLS OAM Alert Mechanisms . . .  8
     3.2. 10
     4.2.  GAL Applicability and Usage  . . . . . . . . . . . . . . .  8
       3.2.1. 10
       4.2.1.  GAL Processing . . . . . . . . . . . . . . . . . . . .  8
     3.3. 10
     4.3.  Relationship wth RFC 3429  . . . . . . . . . . . . . . . . 11
   4. 13
   5.  Compatability  . . . . . . . . . . . . . . . . . . . . . . . . 11
   5. 13
   6.  Congestion Considerations  . . . . . . . . . . . . . . . . . . 12
   6. 14
   7.  Security Consderations . Considerations  . . . . . . . . . . . . . . . . . . . 12
   7. 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8. 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9. 16
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1. 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2. 16
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 17

1.  Introduction

   There is a need for Operations, Administration and Maintenance (OAM)
   mechanisms that can be used for edge-to-edge (i.e. between
   originating fault detection, diagnostics,
   maintenance and terminating LSRs or T-PEs) other functions on a PW and segment (e.g. an LSP.  These functions
   can be used between any two LSRs Label Edge Routers (LERs) / Label
   Switching Router (LSRs) or T-PEs/S-PEs Terminating Provider Edge routers (T-PEs)
   / Switching Provider Edge routers (S-PEs) along the path of a an LSP or
   PW [15]) fault
   detection, diagnostics, maintenance and other functions for a PW and
   a LSP. respectively [15].  Some of these functions can be supported using
   existing tools such as
   VCCV Virtual Circuit Connectivity Verification
   (VCCV) [2], BFD [3], or Bidirectional Forwarding Detection for MPLS LSPs (BFD-
   MPLS)[3], LSP-Ping [4]. [4], or BFD-VCCV [5].  However, a requirement has
   been indicated to augment the this set of maintenance functions, in
   particular
   where when MPLS networks are used for packet transport services
   and transport network operations [16].  Examples of these functions
   include performance monitoring, automatic protection switching, and
   support for management and signaling communication channels.  These
   tools must MUST be applicable to, and function in essentially the same
   manner (from an operational point of view) on both MPLS PWs and PWs, MPLS LSPs. LSPs and
   MPLS Sections.  They must MUST also operate in-band on the PW or LSP such
   that they do not depend on PSN
   routing, Packet Switched Network (PSN) routing or
   on user data traffic or ultimately traffic, and MUST also not depend on PSN or other dynamic control
   plane functions.

   Virtual Circuit Connectivity Verification (VCCV)

   VCCV can use an
   associated channel Associated Channel Header (ACH) to provide a PW-
   associated control channel between a PW's
   ingress and egress points and end points, over which OAM
   and other control messages can be exchanged.  In this document, we propose a generic
   associated channel header (G-ACH)  This document
   generalises the use of the ACH to enable the same associated control
   channel mechanism to be used for MPLS Sections, LSPs and PWs.  The
   associated control channel header (ACH) thus generalized is known as the Generic
   Associated Channel (G-ACh).  The ACH, specified in RFC 4385 [5] is [6], may
   be used with additional code points to support additional MPLS
   maintenance
   functions. functions on the G-ACh.

   Generalizing the ACH associated control channel mechanism to MPLS LSPs and MPLS
   Sections also requires a method to identify that a packet contains a G-ACH an
   ACH followed by a non-service payload.  This  Therefore, this document therefore also
   defines a label based exception mechanism (the Generic Associated channel
   header Label, or GAL) that serves to inform an
   LSR (or LER) that a packet that it receives on an LSP or section Section belongs
   to an associated channel. control channel for that LSP or Section.

   RFC 4379 [4] and BFD for MPLS LSPs BFD-MPLS [3] have defined define alert mechanisms that enable a an
   MPLS LSR to identify and process MPLS OAM packets when
   the OAM packets these are
   encapsulated in an IP header.  These alert mechanisms are based on TTL
   MPLS or PW label Time to Live (TTL) expiration and/or on the use of
   an IP destination address in the range 127/8.  These mechanisms are
   the default mechanisms for identifying MPLS OAM packets when the OAM packets are
   encapsulated in an IP header.  However it may not always be possible
   to use these mechanisms in some MPLS applications, (e.g.  MPLS-TP
   [15]) e.g.  MPLS
   Transport Profile (MPLS-TP) [15], particularly when IP based
   demultiplexing cannot be used.  This document proposes an OPTIONAL defines a mechanism
   that is RECOMMENDED for identifying and demultiplexing encapsulating MPLS OAM and
   other maintenance messages when IP based mechanisms such as those in
   [4] and [3] are not available.  This mechanism MAY be used in
   addition to IP-based mechanisms.

   The G-ACH and GAL mechanisms are mechanism is defined to work together. together with the ACH for LSPs
   and MPLS Sections.

   Note that, in this document, maintenace maintenance functions and packets should
   be understood in the broad sense, that sense.  That is, as a set of FCAPS maintenance and
   management mechanisms that include OAM, Automatic Protection
   Switching (APS), Signalling Communication Channel (SCC) and
   Management Communication Channel (MCC) messages.

   Note

   Also note that the GAL and G-ACH ACH are applicable to MPLS in general.
   Their applicability to specific applications of MPLS is outside the
   scope of this document.  For example, the applicability of the GAL and G-ACH to
   MPLS-TP is described in [15] and [17].

1.1.  Contributing Authors

   The editors gratefully acknowledge the contibution contributions of Stewart Bryant, Sami Boutros,
   Italo Busi, Marc Lasserre, and Lieven Levrau. Levrau and Siva Sivabalan

1.2.  Objectives

   This document proposes defines a mechanism that provides a solution to provide for the
   extended maintenance needs of emerging applications for MPLS.  It
   creates a generic control channel identification mechanism that may be applied to all
   MPLS LSPs, LSPs and Sections, while maintaining compatibility with the PW
   associated channel header (ACH) . channel.  It also normalizes normalises the use of the ACH for PWs in
   a transport context. context, and defines a label based exception mechanism to
   alert LERs/LSRs of the presence of an ACH after the bottom of the
   stack.

1.3.  Scope

   This document defines the encapsulation header for LSP, MPLS Section
   and PW associated channel messages.

   It does not define how associated control channel capabilities are
   signaled or negotiated between LSRs LERs/LSRs or PEs, or the operation of
   various OAM
   functions, nor how the messages transmitted on the associated
   channel. functions.

   This document does not deprecate existing MPLS and PW OAM mechanisms.

1.4.  Terminology

   G-ACH: Generic

   ACH: Associated Channel Header

   GAL:

   G-ACh: Generic Associated Channel Header

   GAL: G-ACh Label
   MPLS Section: A network segment between two LSRs that are immediately
   adjacent at the MPLS layer

   Maintenance Packet: packet: Any packet containing a message belonging to a
   maintenace
   maintenance protocol that is carried on a PW, LSP or MPLS Section
   associated control channel.  Examples of such maintenance protocols
   include OAM functions, signaling communications or management
   communications.

   The terms 'Section' and 'Concatenated Segment' are defined in [17].

2.  Generic Associated Channel Header

   VCCV [2] defines three MPLS Control Channel (CC) Types that may be
   used to multiplex exchange OAM messages onto through a PW: CC Type 1 uses an
   associated channel header ACH and
   is referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router
   Alert Label to indicate VCCV packets and is referred to as "Out of
   Band VCCV"; CC Type 3 uses the TTL to force the packet to be
   processed by the targeted router control plane and is referred to as
   "MPLS PW Label with TTL == 1".

2.1.  Definition

   The use of the CC Type 1, currently previously limited to MPLS PWs, is here extended
   to also apply to MPLS LSPs as well as and to MPLS Sections.  This
   associated channel header is called  Note that for PWs, the Generic Associated Channel
   Header (G- ACH).  The PWE3
   control word [6] MUST be present in the encapsulation of user packets
   when the G-ACH ACH is used to demultiplex realize the associated channel packet on a PW. control channel.

   The CC Type 1 control channel header is depicted in figure below:

    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|A| 1|Version|   Reserved    |         Channel Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: Generic Associated Channel Header

   In the above figure, the first nibble is set to 0001b to indicate a
   control channel associated with a PW, a an LSP or a Section.  The
   Version field is set to 0, as specified in RFC 4385 [5].  This draft allocates Bit
   8 of the ACH to the ACH TLV bit.  This bit is set to 1 to indicate
   that an object defined in the ACH TLV registry immediately follows
   the G-ACH, otherwise it is set to 0. [6].  Bits 8 to
   14 of the G-ACH are reserved and MUST be set to 0.. 0 and ignored on
   reception.

   Note that VCCV also includes mechanisms for negotiating the Control
   Channel and Connectivity Verification (i.e.  OAM functions) Types
   between PEs.  It is anticipated that similar mechanisms will be
   applied to existing MPLS LSPs.  Such application will require further
   specification.  However, such specification is beyond the scope of
   this document.

2.1.

2.2.  Allocation of Channel Types

   The Channel Type field indicates the type of message carried on the
   associated control channel e.g.  IPv4 or IPv6 if IP demultiplexing is
   used for messages sent on the G-ACH, associated control channel, or OAM or
   other FCAPS maintenance function if IP demultiplexing is not used.  For G-ACH
   associated control channel packets where IP is not used as the
   multiplexer, the Channel Type SHOULD indicate the specific
   maintenance protocol carried in the associated control channel.

   Values for the Channel Type field currently used for VCCV are
   specified elsewhere, e.g. in RFC 4446 [6].  The [7]and RFC 4385[6] .
   Additional Channel Type values and the associated maintenance
   functionality of any additional
   channel types will be defined in another document. other documents.  Each associated
   channel document
   specifying a protocol solution document must relying on the ACH MUST also specify
   the value to use for
   any additional channel types. applicable Channel Type field value.

   Note that these values are allocated from the PW Associated Channel
   Type registry, but this document modifies the existing policy to
   accomodate
   accommodate a level of experimentation.  See Section 7 8 for further
   details.

3.  Generalised Exception Mechanism

   The above mechanism enables the multiplexing of various maintenace
   packets onto a PW, LSP or Section and provides information on the
   type of function being performed.  ACH TLVs

   In the case some applications of a PW, the use of a "In-band VCCV" associated control word channel
   it is negotiated necessary to include one or configured at more ACH TLVs to provide additional
   context information to the time maintenance packet.  One use of these ACH
   TLVs might be to identify the PW
   establishment.  A special case source and/or intended destination of
   the associated control word (the G-ACH) channel maintenance message.  However, the use
   of this construct is
   used not limited to identify packets belonging providing addressing information
   nor is the applicability restricted to a PW associated channel.

   Generalizing transport network
   applications.

   If the maintenance message MAY be preceded by one or more ACH mechanism to MPLS LSPs and MPLS TLVs,
   then this MUST be explicitly specified in the definition of an ACH
   Channel Type.  If the ACH Channel Type definition does state that one
   or more ACH TLVs MAY precede the maintenance message, an ACH TLV
   Header MUST follow the ACH.  If no ACH TLVs are required in a
   specific associated control channel packet, but the Channel Type
   nevertheless defines that ACH TLVs MAY be used, an ACH TLV Header
   MUST be present but with a length field set to zero to indicate that
   no ACH TLV follow this header.

   If a channel type specification does not explicitly specify that ACH
   TLVs MAY be used, then an ACH TLV Header MUST NOT be used.

3.1.  ACH TLV Payload Structure

   This section defines and describes the structure of an ACH payload
   when an ACH TLV Header is present.  The structure of ACH TLVs that
   MAY follow an ACH TLV Header is defined and described in the
   following sections.

   The following figure (Figure 2) shows the structure of a G-ACh packet
   payload.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ACH                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         ACH TLV Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                     zero or more ACH TLVs                     ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                      Maintenance Message                      ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: ACH TLV Payload Structure

3.2.  ACH TLV Header

   The ACH TLV Header defines the length of the set of ACH TLVs that
   follow.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Length                 |          Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 3: ACH TLV Header

   The length field specifies the length in octets of the complete set
   of TLVs including TLVs that follow the ACH TLV header.  A length of
   zero indicates that no ACH TLV follow this header.

   The reserved field is for future use and MUST be set to zero on
   transmission and ignored on reception.

3.3.  ACH TLV Object

   An ACH TLV consists of a 16-bit Type field, followed by a 16-bit
   Length field which specifies the number of octets of the Value field
   which follows the Length field.  This 32-bit word is followed by zero
   or more octets of Value information.  The format and semantics of the
   value information are defined by the TLV Type as recorded in the TLV
   Type registry.  See Section 8 for further details.  Note that the
   Value field of ACH TLVs MAY contain sub-TLV objects.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TLV Type            |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                             Value                             ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 4: ACH TLV Format

4.  Generalised Exception Mechanism

   Generalizing the associated channel mechanism to LSPs and Sections
   also requires a method to identify that a packet contains a G-ACH an ACH
   followed by a non-service payload.  This document specifies that a
   label be is used for that purpose and calls this special label the 'Generic Associated channel
   header G-ACh
   Label (GAL)'. (GAL).  One of the reserved label values defined in RFC 3032 [7]
   [8] is assigned for this purpose.  The value of the label is to be
   allocated by IANA; this document suggests the value 13.

   The GAL provides a generalised an alert based exception mechanism to:

   o  Differentiate  differentiate specific packets (e.g. those containing OAM maintenance messages) from
      others, such as normal user-plane ones,

   o  Indicate  indicate that the Generic Associated Channel Header (G-ACH) ACH appears immediately after the bottom of the
      label stack.

   The 'Generic Associated channel header Label (GAL)' GAL MUST only be used where both of these purposes are applicable.

3.1. apply.

4.1.  Relationship with Existing MPLS OAM Alert Mechanisms

   RFC 4379 [4] and BFD for MPLS LSPs BFD-MPLS [3] have defined alert mechanisms that
   enable a MPLS LSR to identify and process MPLS OAM packets when the
   OAM packets are encapsulated in an IP header.  These alert mechanisms
   are based on TTL expiration and/or use an IP destination address in
   the range 127/8.

   These alert mechanisms SHOULD preferably be used in non MPLS-TP
   environments.  The environments,
   although the mechanism defined in this document MAY also be used.

3.2.

4.2.  GAL Applicability and Usage

   The 'Generic Associated channel header Label (GAL)' GAL MUST only be used with Label Switched Paths (LSPs), with their associated Tandem
   Connection Monitoring Entities (see [17] for definitions LSPs, concatenated segments of TCMEs) LSPs,
   and with MPLS Sections.

   The GAL applies to both P2P and P2MP LSPs, unless otherwise stated.

   In MPLS-TP, the GAL MUST always be at the bottom of the label stack
   (i.e.  S bit set to 1).  However, in other MPLS environments, this
   document places no restrictions on where the GAL may appear within
   the label stack.

   The GAL MUST NOT appear in the label stack when transporting normal
   user-plane packets.  Furthermore, when present, the GAL MUST only
   appear once in the label stack for packets on the generic associated channel.

3.2.1. stack.

4.2.1.  GAL Processing

   The Traffic Class (TC) field (formerly known as the EXP field) of the
   label stack entry containing the GAL follows the definition and
   processing rules specified and referenced in [8]. [9].

   The Time-To-Live (TTL) field of the label stack entry that contains
   the GAL follows the definition and processing rules specified in [9].

3.2.1.1.
   [10].

4.2.1.1.  MPLS Section Label Switched Paths and Segments

   The following figure (Figure 2) 5) depicts two MPLS LERs (A and D) and two
   LSRs immediately
   adjacent at the MPLS layer. (B and C) for a given LSP which is established from A to D and
   switched in B and C.

        +---+             +---+             +---+             +---+
        | A |-------------| Z B |-------------| C |-------------| D |
        +---+             +---+             +---+             +---+

                 Figure 2: Maintenance 5: MPLS-TP maintenance over a LSP

   In this example, a G-ACh exists on an MPLS Section Associated Channel

   With regards to the MPLS Section, both LSP that extends between LERs are Maintenance End
   Points (see [17] for definitions of MEPs). A
   and D, via LSRs B and C. Only these nodes may insert, extract or
   process packets on this G-ACh.

   The following figure (Figure 3) 6) depicts the format of a labelled OAM
   packet on an associated channel MPLS-TP
   maintenance message when used for MPLS Section
   maintenance. an LSP.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               LSP Label               |  TC |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  GAL                  |  TC |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Generic-ACH                              ACH                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               .
       .                  ACH TLV Header (if present)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                     Zero or more ACH TLVs                     ~
   ~                           (if present)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                      Maintenance Message                      .
       .                      ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 3: Maintenance Packet Format 6: MPLS-TP maintenance message format for a LSP

   Note that it is possible that the LSP may be tunnelled in another LSP
   (e.g. if a MPLS Section Tunnel exists between B and C), and as such other
   labels may be present in the label stack.

   To send a MPLS-TP maintenance packet message on an associated channel of the
   MPLS Section, the head-end LSR (A) of LSP associated control channel,
   the MPLS Section LER (A) generates a maintenance packet message, to which it MAY
   prepended an ACH TLV header and appropriate ACH TLVs, and with a G-ACH ACH
   to which it pushes a GAL. GAL and finally the LSP label.

   o  The TTL field of the GAL SHOULD MUST be set to at least 1.  The exact
      value of the TTL is application specific.

   o  The S bit of the GAL MUST be set according to 1 its position in MPLS-TP. the
      label stack.

   o  The setting of the TC field is application specific.

   The maintenance packet, message, the G-ACH and ACH or the GAL SHOULD NOT be modified
   towards the tail-end LSR (Z). targeted destination.  Upon reception of the labelled
   packet, the tail-end LSR (Z), targeted destination, after having checked both the LSP
   label and GAL fields, SHOULD pass the whole packet maintenance message to
   the appropriate processing entity.

3.2.1.2.  Label Switched Paths

4.2.1.2.  MPLS Section

   The following figure (Figure 4) 7) depicts four LSRs.  A LSP is
   established from A to D and switched in B and C.

           +---+             +---+ an example of a MPLS Section.

                          +---+             +---+
                          | A |-------------| B |-------------| C |-------------| D Z |
                          +---+             +---+             +---+             +---+

                Figure 4: 7: Maintenance over an LSP Associated Channel

   LERs MPLS Section

   With regard to the MPLS Section, a G-ACh exists between A and D are Maintenance End Points (MEPs) with respect to this
   LSP.  Furthermore, LSRs B Z. Only
   A and C could also be Maintenance
   Intermediate Points (MIPs) with respect to Z can insert, extract or process packets on this LSP (see [17] for
   definitions of MEPs and MIPs). G-ACh.

   The following figure (Figure 5) 8) depicts the format of a labelled maintenance packet
   message when used for a MPLS-TP LSP. MPLS Section.  The GAL MAY provide the
   exception mechanism for a control channel in its own right without
   being associated with a specific LSP, thus providing maintenance
   related communications across a specific link interconnecting two
   LSRs.  In this case, the GAL is the only label in the stack.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               LSP Label               |  TC |S|       TTL     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  GAL                  |  TC |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Generic-ACH                             ACH                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               .
       .                      Maintenance Message                      .
       .                  ACH TLV Header (if present)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 5: Maintenance Packet Format for MPLS-TP LSP

   Note that it is possible that the LSP MAY also be tunnelled in
   another LSP (e.g. if
   |                                                               ~
   ~                     Zero or more ACH TLVs                     ~
   ~                         (if present)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                      Maintenance Message                      ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 8: Maintenance message format for a MPLS Tunnel exists between B and C), and as
   such other labels MAY be present above it in the label stack. Section

   To send a maintenance packet message on the LSP a control channel associated channel, to the head-
   end
   Section, the head-end LSR (A) of the Section generates a OAM message maintenance
   message, to which it MAY prepend an ACH TLV Header and appropriate
   ACH TLVs, and with a G-ACH on ACH to which it first pushes a GAL followed by the LSP label. GAL.

   o  The TTL field of the GAL SHOULD MUST be set to at least 1.  The exact
      value of the TTL is application specific.

   o  The S bit of the GAL SHOULD MUST be set according to 1 its position in MPLS-TP. the
      label stack.  For MPLS Sections, the S bit MUST be set to 1.

   o  The setting of the TC field is application specific.

   The maintenance message, the G-ACH or ACH and the GAL SHOULD NOT be modified
   towards the targeted destination. tail-end LSR (Z).  Upon reception of the labelled packet,
   the targeted destination, tail-end LSR (Z), after having checked both the LSP
   label and GAL fields, SHOULD
   pass the whole packet to the appropriate processing entity.

3.2.1.3.  Tandem Connection Monitoring Entity

   Tandem Connection Monitoring will be specified in a separate
   document.

3.3.

4.3.  Relationship wth RFC 3429

   RFC 3429 [18] describes the assignment of one of the reserved label
   values, defined in RFC 3032 [7], [8], to the 'OAM Alert Label' that is
   used by user-plane MPLS OAM functions for the identification of MPLS
   OAM packets.  The value of 14 is used for that purpose.

   Both this document and RFC 3429 [18] therefore describe the
   assignment of reserved label values for similar purposes.  The
   rationale for the assignment of a new reserved label can be
   summarized as follows:

   o  Unlike the mechanisms described and referenced in RFC 3429 [18],
      MPLS-TP OAM packet payloads maintenance messages will not reside immediately after the
      GAL but instead behind the G-ACH, ACH, which itself resides immediately after the
      bottom of the label stack when the GAL is present. stack.  This ensures that OAM OAM, using the generic associated channel
      G-ACh, complies with RFC 4928 [10]. [11].

   o  The set of maintenance functions potentially operated in the
      context of the generic associated channel G-ACh is wider than the set of OAM functions
      referenced in RFC 3429 [18].

   o  It has been reported that there are existing implementations and
      running deployments using the 'OAM Alert Label' as described in
      RFC 3429 [18].  It is therefore not possible to modify the 'OAM
      Alert Label' allocation, purpose or usage.  Nevertheless, it is
      RECOMMENDED by this document that no further OAM extensions based
      on 'OAM Alert Label' (Label 14) usage be specified or developed.

4.

5.  Compatability

   Procedures for handling a packet received with an invalid incoming
   label are specified in RFC 3031[12].

   An LER, LSR or PE MUST discard received G-ACH associated channel packets on
   which all of the MPLS or PW labels have been popped if it any one of the
   following conditions is not G-
   ACH capable, if it true:

   o  It is not capable of processing packets on the Channel Type
      indicated G-ACH channel, or if it by the ACH of the received packet.

   o  It has not, through means outside the scope of this document,
      indicated to the sending LSR, LER or PE that it will process G-ACH
      associated channel packets received on the Channel Type indicated channel. by the
      ACH of the received packet.

   o  If the ACH was indicated by the presence of a GAL, and the first
      nibble of the ACH of the received packet is not 0b0001.

   o  The
   LER, LSR or PE ACH version is not recognised.

   In addition, it MAY increment an error counter and MAY also
   optionally issue a system and/or SNMP notification.

5.

6.  Congestion Considerations

   The congestion considerations detailed in RFC 5085 [2] apply.
   Further generic associated channel-specific congestion considerations
   will be detailed in a future revision of this document.

6.

7.  Security Consderations Considerations

   The security considerations detailed for the associated control channel are
   described in RFC 5085 [2], the MPLS
   architecture [11], 4385[6].  Further security considerations MUST be
   described in the PWE3 architecture [12] and relevant associated channel type specification.

   RFC 5085 [2] provides data plane related security considerations.
   These also apply to a G-ACh, whether the MPLS-TP
   framework [15] apply.

7. alert mechanism uses a GAL
   or only an ACH.

8.  IANA Considerations

   This document requests that IANA allocates a Label label value, to the
   'Generic Associated channel header Label (GAL)', GAL,
   from the pool of reserved labels, and suggests this value to be 13.

   Channel Types for the Generic Associated Channel Header are allocated from
   the IANA PW Associated Channel Type registry [6]. [7].  The PW Associated
   Channel Type registry is currently allocated based on the IETF
   consensus process, described in[13]. in [13].  This allocation process was
   chosen based on the consensus reached in the PWE3 working group that
   pseudowire associated channel mechanisms should be reviewed by the
   IETF and only those that are consistent with the PWE3 architecture
   and requirements should be allocated a code point.

   However, a requirement has emerged (see [16]) to allow for
   optimizations or extensions to OAM and other control protocols
   running in an associated channel to be experimented with without resorting
   to the IETF standards process, by supporting experimental code
   points.  This would prevent code points used for such functions from
   being used from the range allocated through the IETF standards and
   thus protects an installed base of equipment from potential
   inadvertent overloading of code points.  In order to support this
   requirement, this document requests that the code-point code point allocation
   scheme for the PW Associated Channel Type be changed as follows:

   0 - 32751 : IETF Consensus

   32752 - 32767 : Experimental

   Code points in the experimental range MUST be used according to the
   guidelines of RFC 3692 [14].  Experimental OAM functions MUST be
   disabled by default.  The channel type Channel Type value used for a given
   experimental OAM function MUST be configurable, and care MUST be
   taken to ensure that different OAM functions that are not
   interoperable inter-
   operable are configured to use different channel type Channel Type values.

8.

   The PW Associated Channel Type registry needs to be updated to
   include a column indicating whether the ACH is followed by a ACH TLV
   header (Yes/No).  There are two ACH Channel Type code-points
   currently assigned and in both cases no ACH TLV header is used.  Thus
   the new format of the PW Channel Type registry is:

   Registry:
   Value  Description                   TLV Follows  Reference
   -----  ----------------------------  -----------  ---------
   0x21   ACH carries an IPv4 packet    No           [RFC4385]
   0x57   ACH carries an IPv6 packet    No           [RFC4385]

                    Figure 9: PW Channel Type registry

   IANA is requested create a new registry called the Associated Channel
   TLV Registry.  The allocation policy for this registry is IETF
   consensus.  This registry MUST record the following information.
   There are no initial entries.

   Name       Type  Length   Description                  Reference
                   (octets)

                      Figure 10: PW ACH TLV registry

9.  Acknowledgements

   The authors would like to thank all members of the teams (the Joint
   Working Team, the MPLS Interoperability Design Team in IETF and the
   T-MPLS Ad Hoc Group
   MPLS-TP Ad-Hoc Team in ITU-T) involved in the definition and
   specification of MPLS Transport Profile.

9.

10.  References

9.1.

10.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, December 2007.

   [3]   Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
         For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
         June 2008.

   [4]   Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
         Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.

   [5]   Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
         Detection (BFD) for the Pseudowire Virtual Circuit
         Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-03
         (work in progress), February 2009.

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

   [6]

   [7]   Martini, L., "IANA Allocations for Pseudowire Edge to Edge
         Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

   [7]

   [8]   Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,
         D., Li, T., and A. Conta, "MPLS Label Stack Encoding",
         RFC 3032, January 2001.

   [8]

   [9]   Andersson, L. and R. Asati, "Multi-Protocol Label Switching
         (MPLS) label stack entry: "EXP" field renamed  to "Traffic
         Class" field", draft-ietf-mpls-cosfield-def-08 (work in
         progress), December 2008.

   [9]

   [10]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
         Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
         January 2003.

   [10]

   [11]  Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost
         Multipath Treatment in MPLS Networks", BCP 128, RFC 4928,
         June 2007.

   [11]

   [12]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
         Switching Architecture", RFC 3031, January 2001.

   [12]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
         (PWE3) Architecture", RFC 3985, March 2005.

   [13]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998. 5226, May 2008.

   [14]  Narten, T., "Assigning Experimental and Testing Numbers
         Considered Useful", BCP 82, RFC 3692, January 2004.

9.2.

10.2.  Informative References

   [15]  Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in
         Transport Networks", draft-ietf-mpls-tp-framework-00 (work in
         progress), November 2008.

   [16]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in
         MPLS Transport Networks",
         draft-ietf-mpls-tp-oam-requirements-00 (work in progress),
         December 2008.

   [17]  Busi, I. and B.  Niven-Jenkins, "MPLS-TP OAM Framework B., Brungard, D., Betts, M., Sprecher, N., and
         Overview", draft-busi-mpls-tp-oam-framework-00
         S. Ueno, "MPLS-TP Requirements",
         draft-ietf-mpls-tp-requirements-04 (work in progress), October 2008.
         February 2009.

   [18]  Ohta, H., "Assignment of the 'OAM Alert Label' for
         Multiprotocol Label Switching Architecture (MPLS) Operation and
         Maintenance (OAM) Functions", RFC 3429, November 2002.

Authors' Addresses

   Matthew Bocci (editor)
   Alcatel-Lucent
   Voyager Place, Shoppenhangers Road
   Maidenhead, Berks  SL6 2PJ
   UK

   Email: matthew.bocci@alcatel-lucent.com
   Martin Vigoureux (editor)
   Alcatel-Lucent
   Route de Villejust
   Nozay,   91620
   France

   Email: martin.vigoureux@alcatel-lucent.com

   George Swallow
   Cisco

   Email: swallow@cisco.com

   David Ward
   Cisco

   Email: dward@cisco.com

   Stewart Bryant
   Cisco

   Email: stbryant@cisco.com

   Rahul Aggarwal
   Juniper Networks

   Email: rahul@juniper.net