doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc6370.txt b/doc/rfc/rfc6370.txt
new file mode 100644
index 0000000..7ab2b41
--- /dev/null
+++ b/doc/rfc/rfc6370.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          M. Bocci
+Request for Comments: 6370                                Alcatel-Lucent
+Category: Standards Track                                     G. Swallow
+ISSN: 2070-1721                                                    Cisco
+                                                                 E. Gray
+                                                                Ericsson
+                                                          September 2011
+
+
+              MPLS Transport Profile (MPLS-TP) Identifiers
+
+Abstract
+
+   This document specifies an initial set of identifiers to be used in
+   the Transport Profile of Multiprotocol Label Switching (MPLS-TP).
+   The MPLS-TP requirements (RFC 5654) require that the elements and
+   objects in an MPLS-TP environment are able to be configured and
+   managed without a control plane.  In such an environment, many
+   conventions for defining identifiers are possible.  This document
+   defines identifiers for MPLS-TP management and Operations,
+   Administration, and Maintenance (OAM) functions compatible with IP/
+   MPLS conventions.
+
+   This document is a product of a joint Internet Engineering Task Force
+   (IETF) / International Telecommunication Union Telecommunication
+   Standardization Sector (ITU-T) effort to include an MPLS Transport
+   Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
+   (PWE3) architectures to support the capabilities and functionalities
+   of a packet transport network as defined by the ITU-T.
+
+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/rfc6370.
+
+
+
+
+
+
+
+
+Bocci, et al.                Standards Track                    [Page 1]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................3
+      1.2. Requirements Language ......................................4
+      1.3. Notational Conventions .....................................4
+   2. Named Entities ..................................................5
+   3. Uniquely Identifying an Operator - the Global_ID ................5
+   4. Node and Interface Identifiers ..................................6
+   5. MPLS-TP Tunnel and LSP Identifiers ..............................7
+      5.1. MPLS-TP Point-to-Point Tunnel Identifiers ..................8
+      5.2. MPLS-TP LSP Identifiers ....................................9
+           5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers .....9
+           5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers ....9
+      5.3. Mapping to RSVP Signaling .................................10
+   6. Pseudowire Path Identifiers ....................................11
+   7. Maintenance Identifiers ........................................13
+      7.1. Maintenance Entity Group Identifiers ......................13
+           7.1.1. MPLS-TP Section MEG_IDs ............................13
+           7.1.2. MPLS-TP LSP MEG_IDs ................................13
+           7.1.3. Pseudowire MEG_IDs .................................14
+      7.2. Maintenance Entity Group End Point Identifiers ............14
+           7.2.1. MPLS-TP Section MEP_IDs ............................14
+           7.2.2. MPLS-TP LSP_MEP_ID .................................15
+           7.2.3. MEP_IDs for Pseudowires ............................15
+      7.3. Maintenance Entity Group Intermediate Point Identifiers ...15
+   8. Security Considerations ........................................15
+   9. References .....................................................16
+      9.1. Normative References ......................................16
+      9.2. Informative References ....................................17
+
+
+
+
+
+
+Bocci, et al.                Standards Track                    [Page 2]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+1.  Introduction
+
+   This document specifies an initial set of identifiers to be used in
+   the Transport Profile of Multiprotocol Label Switching (MPLS-TP).
+   The MPLS-TP requirements (RFC 5654 [7]) require that the elements and
+   objects in an MPLS-TP environment are able to be configured and
+   managed without a control plane.  In such an environment, many
+   conventions for defining identifiers are possible.  This document
+   defines identifiers for MPLS-TP management and OAM functions
+   compatible with IP/MPLS conventions.  That is, the identifiers have
+   been chosen to be compatible with existing IP, MPLS, GMPLS, and
+   Pseudowire definitions.
+
+   This document is a product of a joint Internet Engineering Task Force
+   (IETF) / International Telecommunication Union Telecommunication
+   Standardization Sector (ITU-T) effort to include an MPLS Transport
+   Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
+   (PWE3) architectures to support the capabilities and functionalities
+   of a packet transport network as defined by the ITU-T.
+
+1.1.  Terminology
+
+   AGI: Attachment Group Identifier
+
+   AII: Attachment Interface Identifier
+
+   AS: Autonomous System
+
+   ASN: Autonomous System Number
+
+   EGP: Exterior Gateway Protocol
+
+   FEC: Forwarding Equivalence Class
+
+   GMPLS: Generalized Multiprotocol Label Switching
+
+   IGP: Interior Gateway Protocol
+
+   LSP: Label Switched Path
+
+   LSR: Label Switching Router
+
+   MEG: Maintenance Entity Group
+
+   MEP: Maintenance Entity Group End Point
+
+   MIP: Maintenance Entity Group Intermediate Point
+
+
+
+
+Bocci, et al.                Standards Track                    [Page 3]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+   MPLS: Multiprotocol Label Switching
+
+   NNI: Network-to-Network Interface
+
+   OAM: Operations, Administration, and Maintenance
+
+   PW: Pseudowire
+
+   RSVP: Resource Reservation Protocol
+
+   RSVP-TE: RSVP Traffic Engineering
+
+   SAII: Source AII
+
+   SPME: Sub-Path Maintenance Entity
+
+   T-PE: Terminating Provider Edge
+
+   TAII: Target AII
+
+1.2.  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].
+
+1.3.  Notational Conventions
+
+   All multiple-word atomic identifiers use underscores (_) between the
+   words to join the words.  Many of the identifiers are composed of a
+   set of other identifiers.  These are expressed by listing the latter
+   identifiers joined with double-colon "::" notation.
+
+   Where the same identifier type is used multiple times in a
+   concatenation, they are qualified by a prefix joined to the
+   identifier by a dash (-).  For example, A1-Node_ID is the Node_ID of
+   a node referred to as A1.
+
+   The notation defines a preferred ordering of the fields.
+   Specifically, the designation A1 is used to indicate the lower sort
+   order of a field or set of fields and Z9 is used to indicate the
+   higher sort order of the same.  The sort is either alphanumeric or
+   numeric depending on the field's definition.  Where the sort applies
+   to a group of fields, those fields are grouped with {...}.
+
+   Note, however, that the uniqueness of an identifier does not depend
+   on the ordering, but rather, upon the uniqueness and scoping of the
+   fields that compose the identifier.  Further, the preferred ordering
+
+
+
+Bocci, et al.                Standards Track                    [Page 4]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+   is not intended to constrain protocol designs by dictating a
+   particular field sequence (for example, see Section 5.2.1) or even
+   what fields appear in which objects (for example, see Section 5.3).
+
+2.  Named Entities
+
+   In order to configure, operate, and manage a transport network based
+   on the MPLS Transport Profile, a number of entities require
+   identification.  Identifiers for the following entities are defined
+   in this document:
+
+      *  Global_ID
+
+      *  Node
+
+      *  Interface
+
+      *  Tunnel
+
+      *  LSP
+
+      *  PW
+
+      *  MEG
+
+      *  MEP
+
+      *  MIP
+
+   Note that we have borrowed the term "tunnel" from RSVP-TE (RFC 3209
+   [2]) where it is used to describe an entity that provides a logical
+   association between a source and destination LSR.  The tunnel, in
+   turn, is instantiated by one or more LSPs, where the additional LSPs
+   are used for protection or re-grooming of the tunnel.
+
+3.  Uniquely Identifying an Operator - the Global_ID
+
+   The Global_ID is defined to uniquely identify an operator.  RFC 5003
+   [3] defines a globally unique Attachment Interface Identifier (AII).
+   That AII is composed of three parts: a Global_ID that uniquely
+   identifies an operator, a prefix, and, finally, an attachment circuit
+   identifier.  We have chosen to use that Global ID for MPLS-TP.
+   Quoting from RFC 5003, Section 3.2:
+
+      The global ID can contain the 2-octet or 4-octet value of the
+      provider's Autonomous System Number (ASN).  It is expected that
+      the global ID will be derived from the globally unique ASN of the
+
+
+
+
+Bocci, et al.                Standards Track                    [Page 5]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+      autonomous system hosting the PEs containing the actual AIIs.  The
+      presence of a global ID based on the operator's ASN ensures that
+      the AII will be globally unique.
+
+   A Global_ID is an unsigned 32-bit value and MUST be derived from a
+   4-octet AS number assigned to the operator.  Note that 2-octet AS
+   numbers have been incorporated in the 4-octet by placing the 2-octet
+   AS number in the low-order octets and setting the two high-order
+   octets to zero.
+
+   ASN 0 is reserved and cannot be assigned to an operator.  An
+   identifier containing a Global_ID of zero means that no Global_ID is
+   specified.  Note that a Global_ID of zero is limited to entities
+   contained within a single operator and MUST NOT be used across an
+   NNI.
+
+   The Global_ID is used solely to provide a globally unique context for
+   other MPLS-TP identifiers.  While the AS number used in the Global_ID
+   MUST be one that the operator is entitled to use, the use of the
+   Global_ID is not related to the use of the ASN in protocols such as
+   BGP.
+
+4.  Node and Interface Identifiers
+
+   An LSR requires identification of the node itself and of its
+   interfaces.  An interface is the attachment point to a server
+   (sub-)layer, e.g., MPLS-TP section or MPLS-TP tunnel.
+
+   We call the identifier associated with a node a "Node Identifier"
+   (Node_ID).  The Node_ID is a unique 32-bit value assigned by the
+   operator within the scope of a Global_ID.  The structure of the
+   Node_ID is operator-specific and is outside the scope of this
+   document.  However, the value zero is reserved and MUST NOT be used.
+   Where IPv4 addresses are used, it may be convenient to use the Node's
+   IPv4 loopback address as the Node_ID; however, the Node_ID does not
+   need to have any association with the IPv4 address space used in the
+   operator's IGP or EGP.  Where IPv6 addresses are used exclusively, a
+   32-bit value unique within the scope of a Global_ID is assigned.
+
+   An LSR can support multiple layers (e.g., hierarchical LSPs) and the
+   Node_ID belongs to the multiple-layer context, i.e., it is applicable
+   to all LSPs or PWs that originate on, have an intermediate point on,
+   or terminate on the node.
+
+   In situations where a Node_ID needs to be globally unique, this is
+   accomplished by prefixing the identifier with the operator's
+   Global_ID.
+
+
+
+
+Bocci, et al.                Standards Track                    [Page 6]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+   The term "interface" is used for the attachment point to an MPLS-TP
+   section.  Within the context of a particular node, we call the
+   identifier associated with an interface an "Interface Number"
+   (IF_Num).  The IF_Num is a 32-bit unsigned integer assigned by the
+   operator and MUST be unique within the scope of a Node_ID.  The
+   IF_Num value 0 has special meaning (see Section 7.3, MIP Identifiers)
+   and MUST NOT be used to identify an MPLS-TP interface.
+
+   Note that IF_Num has no relation with the ifNum object defined in RFC
+   2863 [8].  Further, no mapping is mandated between IF_Num and ifIndex
+   in RFC 2863.
+
+   An "Interface Identifier" (IF_ID) identifies an interface uniquely
+   within the context of a Global_ID.  It is formed by concatenating the
+   Node_ID with the IF_Num.  That is, an IF_ID is a 64-bit identifier
+   formed as Node_ID::IF_Num.
+
+   This convention was chosen to allow compatibility with GMPLS.  The
+   GMPLS signaling functional description [4] requires interface
+   identification.  GMPLS allows three formats for the Interface_ID.
+   The third format consists of an IPv4 address plus a 32-bit unsigned
+   integer for the specific interface.  The format defined for MPLS-TP
+   is consistent with this format, but uses the Node_ID instead of an
+   IPv4 address.
+
+   If an IF_ID needs to be globally unique, this is accomplished by
+   prefixing the identifier with the operator's Global_ID.
+
+   Note that MPLS-TP supports hierarchical sections.  The attachment
+   point to an MPLS-TP section at any (sub-)layer requires a node-unique
+   IF_Num.
+
+5.  MPLS-TP Tunnel and LSP Identifiers
+
+   In MPLS, the actual transport of packets is provided by Label
+   Switched Paths (LSPs).  A transport service may be composed of
+   multiple LSPs.  Further, the LSPs providing a service may change over
+   time due to protection and restoration events.  In order to clearly
+   identify the service, we use the term "MPLS-TP Tunnel" or simply
+   "tunnel" for a service provided by (for example) a working LSP and
+   protected by a protection LSP.  The "Tunnel Identifier" (Tunnel_ID)
+   identifies the transport service and provides a stable binding to the
+   client in the face of changes in the data-plane LSPs used to provide
+   the service due to protection or restoration events.  This section
+   defines an MPLS-TP Tunnel_ID to uniquely identify a tunnel, and an
+   MPLS-TP LSP Identifier (LSP_ID) to uniquely identify an LSP
+   associated with a tunnel.
+
+
+
+
+Bocci, et al.                Standards Track                    [Page 7]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+   For the case where multiple LSPs (for example) are used to support a
+   single service with a common set of end points, using the Tunnel_ID
+   allows for a trivial mapping between the server and client layers,
+   providing a common service identifier that may be either defined by
+   or used by the client.
+
+   Note that this usage is not intended to constrain protection schemes,
+   and may be used to identify any service (protected or unprotected)
+   that may appear to the client as a single service attachment point.
+   Keeping the Tunnel_ID consistent across working and protection LSPs
+   is a useful construct currently employed within GMPLS.  However, the
+   Tunnel_ID for a protection LSP MAY differ from that used by its
+   corresponding working LSP.
+
+5.1.  MPLS-TP Point-to-Point Tunnel Identifiers
+
+   At each end point, a tunnel is uniquely identified by the end point's
+   Node_ID and a locally assigned tunnel number.  Specifically, a
+   "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique
+   within the context of the Node_ID.  The motivation for each end point
+   having its own tunnel number is to allow a compact form for the
+   MEP_ID.  See Section 7.2.2.
+
+   Having two tunnel numbers also serves to simplify other signaling
+   (e.g., setup of associated bidirectional tunnels as described in
+   Section 5.3).
+
+   The concatenation of the two end point identifiers serves as the full
+   identifier.  Using the A1/Z9 convention, the format of a Tunnel_ID
+   is:
+
+      A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}
+
+   Where the Tunnel_ID needs to be globally unique, this is accomplished
+   by using globally unique Node_IDs as defined above.  Thus, a globally
+   unique Tunnel_ID becomes:
+
+      A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::Node_ID::
+      Tunnel_Num}
+
+   When an MPLS-TP Tunnel is configured, it MUST be assigned a unique
+   IF_ID at each end point.  As usual, the IF_ID is composed of the
+   local Node_ID concatenated with a 32-bit IF_Num.
+
+
+
+
+
+
+
+
+Bocci, et al.                Standards Track                    [Page 8]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+5.2.  MPLS-TP LSP Identifiers
+
+   This section defines identifiers for MPLS-TP co-routed bidirectional
+   and associated bidirectional LSPs.  Note that MPLS-TP Sub-Path
+   Maintenance Entities (SPMEs), as defined in RFC 5921 [9], are also
+   LSPs and use these same forms of identifiers.
+
+5.2.1.  MPLS-TP Co-Routed Bidirectional LSP Identifiers
+
+   A co-routed bidirectional LSP can be uniquely identified by a single
+   LSP number within the scope of an MPLS-TP Tunnel_ID.  Specifically,
+   an LSP Number (LSP_Num) is a 16-bit unsigned integer unique within
+   the Tunnel_ID.  Thus, the format of an MPLS-TP co-routed
+   bidirectional LSP_ID is:
+
+      A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num
+
+   Note that the uniqueness of identifiers does not depend on the A1/Z9
+   sort ordering.  Thus, the identifier:
+
+      Z9-{Node_ID::Tunnel_Num}::A1-{Node_ID::Tunnel_Num}::LSP_Num
+
+   is synonymous with the one above.
+
+   At the data-plane level, a co-routed bidirectional LSP is composed of
+   two unidirectional LSPs traversing the same links in opposite
+   directions.  Since a co-routed bidirectional LSP is provisioned or
+   signaled as a single entity, a single LSP_Num is used for both
+   unidirectional LSPs.  The unidirectional LSPs can be referenced by
+   the identifiers:
+
+      A1-Node_ID::A1-Tunnel_Num::LSP_Num::Z9-Node_ID and
+
+      Z9-Node_ID::Z9-Tunnel_Num::LSP_Num::A1-Node_ID, respectively.
+
+   Where the LSP_ID needs to be globally unique, this is accomplished by
+   using globally unique Node_IDs as defined above.  Thus, a globally
+   unique LSP_ID becomes:
+
+      A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::
+      Node_ID::Tunnel_Num}::LSP_Num
+
+5.2.2.  MPLS-TP Associated Bidirectional LSP Identifiers
+
+   For an associated bidirectional LSP, each of the unidirectional LSPs
+   from A1 to Z9 and Z9 to A1 require LSP_Nums.  Each unidirectional LSP
+   is uniquely identified by a single LSP number within the scope of the
+   ingress's Tunnel_Num.  Specifically, an "LSP Number" (LSP_Num) is a
+
+
+
+Bocci, et al.                Standards Track                    [Page 9]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+   16-bit unsigned integer unique within the scope of the ingress's
+   Tunnel_Num.  Thus, the format of an MPLS-TP associated bidirectional
+   LSP_ID is:
+
+      A1-{Node_ID::Tunnel_Num::LSP_Num}::
+      Z9-{Node_ID::Tunnel_Num::LSP_Num}
+
+   At the data-plane level, an associated bidirectional LSP is composed
+   of two unidirectional LSPs between two nodes in opposite directions.
+   The unidirectional LSPs may be referenced by the identifiers:
+
+      A1-Node_ID::A1-Tunnel_Num::A1-LSP_Num::Z9-Node_ID and
+
+      Z9-Node_ID::Z9-Tunnel_Num::Z9-LSP_Num::A1-Node_ID, respectively.
+
+   Where the LSP_ID needs to be globally unique, this is accomplished by
+   using globally unique Node_IDs as defined above.  Thus, a globally
+   unique LSP_ID becomes:
+
+      A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
+      Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}
+
+5.3.  Mapping to RSVP Signaling
+
+   This section is informative and exists to help understand the
+   structure of the LSP IDs.
+
+   GMPLS [5] is based on RSVP-TE [2].  This section defines the mapping
+   from an MPLS-TP LSP_ID to RSVP-TE.  At this time, RSVP-TE has yet to
+   be extended to accommodate Global_IDs.  Thus, a mapping is only made
+   for the network unique form of the LSP_ID and assumes that the
+   operator has chosen to derive its Node_IDs from valid IPv4 addresses.
+
+   GMPLS and RSVP-TE signaling use a 5-tuple to uniquely identify an LSP
+   within an operator's network.  This tuple is composed of a Tunnel
+   End-point Address, Tunnel_ID, Extended Tunnel ID, Tunnel Sender
+   Address, and (RSVP) LSP_ID.  RFC 3209 allows some flexibility in how
+   the Extended Tunnel ID is chosen, and a direct mapping is not
+   mandated.  One convention that is often used, however, is to populate
+   this field with the same value as the Tunnel Sender Address.  The
+   examples below follow that convention.  Note that these are only
+   examples.
+
+
+
+
+
+
+
+
+
+Bocci, et al.                Standards Track                   [Page 10]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+   For a co-routed bidirectional LSP signaled from A1 to Z9, the mapping
+   to the GMPLS 5-tuple is as follows:
+
+      *  Tunnel End-point Address = Z9-Node_ID
+
+      *  Tunnel_ID = A1-Tunnel_Num
+
+      *  Extended Tunnel_ID = A1-Node_ID
+
+      *  Tunnel Sender Address = A1-Node_ID
+
+      *  (RSVP) LSP_ID = LSP_Num
+
+   An associated bidirectional LSP between two nodes A1 and Z9 consists
+   of two unidirectional LSPs, one from A1 to Z9 and one from Z9 to A1.
+
+   In situations where a mapping to the RSVP-TE 5-tuples is required,
+   the following mappings are used.  For the A1 to Z9 LSP, the mapping
+   would be:
+
+      *  Tunnel End-point Address = Z9-Node_ID
+
+      *  Tunnel_ID = A1-Tunnel_Num
+
+      *  Extended Tunnel_ID = A1-Node_ID
+
+      *  Tunnel Sender Address = A1-Node_ID
+
+      *  (RSVP) LSP_ID = A1-LSP_Num
+
+   Likewise, the Z9 to A1 LSP, the mapping would be:
+
+      *  Tunnel End-point Address = A1-Node_ID
+
+      *  Tunnel_ID = Z9-Tunnel_Num
+
+      *  Extended Tunnel_ID = Z9-Node_ID
+
+      *  Tunnel Sender Address = Z9-Node_ID
+
+      *  (RSVP) LSP_ID = Z9-LSP_Num
+
+6.  Pseudowire Path Identifiers
+
+   Pseudowire signaling (RFC 4447 [6]) defines two FECs used to signal
+   pseudowires.  Of these, the Generalized PWid FEC (type 129) along
+   with AII Type 2 as defined in RFC 5003 [3] fits the identification
+   requirements of MPLS-TP.
+
+
+
+Bocci, et al.                Standards Track                   [Page 11]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+   In an MPLS-TP environment, a PW is identified by a set of identifiers
+   that can be mapped directly to the elements required by the
+   Generalized PWid FEC (type 129) and AII Type 2.  To distinguish this
+   identifier from other Pseudowire Identifiers, we call this a
+   Pseudowire Path Identifier (PW_Path_ID).
+
+   The AII Type 2 is composed of three fields.  These are the Global_ID,
+   the Prefix, and the AC_ID.  The Global_ID used in this document is
+   identical to the Global_ID defined in RFC 5003.  The Node_ID is used
+   as the Prefix.  The AC_ID is as defined in RFC 5003.
+
+   To complete the Generalized PWid FEC (type 129), all that is required
+   is an Attachment Group Identifier (AGI).  That field is exactly as
+   specified in RFC 4447.  A (bidirectional) pseudowire consists of a
+   pair of unidirectional LSPs, one in each direction.  Thus, for
+   signaling, the Generalized PWid FEC (type 129) has a notion of Source
+   AII (SAII) and Target AII (TAII).  These terms are used relative to
+   the direction of the LSP, i.e., the SAII is assigned to the end that
+   allocates the PW label for a given direction, and the TAII to the
+   other end.
+
+   In a purely configured environment, when referring to the entire PW,
+   this distinction is not critical.  That is, a Generalized PWid FEC
+   (type 129) of AGIa::AIIb::AIIc is equivalent to AGIa::AIIc::AIIb.
+
+   We note that in a signaled environment, the required convention in
+   RFC 4447 is that at a particular end point, the AII associated with
+   that end point comes first.  The complete PW_Path_ID is:
+
+      AGI::A1-{Global_ID::Node_ID::AC_ID}::
+      Z9-{Global_ID::Node_ID::AC_ID}.
+
+   In a signaled environment the LSP from A1 to Z9 would be initiated
+   with a label request from A1 to Z9 with the fields of the Generalized
+   PWid FEC (type 129) completed as follows:
+
+      AGI = AGI
+      SAII = A1-{Global_ID::Node_ID::AC_ID}
+      TAII = Z9-{Global_ID::Node_ID::AC_ID}
+
+   The LSP from Z9 to A1 would signaled with:
+
+      AGI = AGI
+      SAII = Z9-{Global_ID::Node_ID::AC_ID}
+      TAII = A1-{Global_ID::Node_ID::AC_ID}
+
+
+
+
+
+
+Bocci, et al.                Standards Track                   [Page 12]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+7.  Maintenance Identifiers
+
+   In MPLS-TP, a Maintenance Entity Group (MEG) represents an entity
+   that requires management and defines a relationship between a set of
+   maintenance points.  A maintenance point is either a Maintenance
+   Entity Group End Point (MEP), a Maintenance Entity Group Intermediate
+   Point (MIP), or a Pseudowire Segment End Point.  Within the context
+   of a MEG, MEPs and MIPs must be uniquely identified.  This section
+   defines a means of uniquely identifying Maintenance Entity Groups and
+   Maintenance Entities.  It also uniquely defines MEPs and MIPs within
+   the context of a Maintenance Entity Group.
+
+7.1.  Maintenance Entity Group Identifiers
+
+   Maintenance Entity Group Identifiers (MEG_IDs) are required for
+   MPLS-TP sections, LSPs, and Pseudowires.  The formats were chosen to
+   follow the IP-compatible identifiers defined above.
+
+7.1.1.  MPLS-TP Section MEG_IDs
+
+   MPLS-TP allows a hierarchy of sections.  See "MPLS-TP Data Plane
+   Architecture" (RFC 5960 [10]).  Sections above layer 0 are MPLS-TP
+   LSPs.  These use their MPLS-TP LSP MEG IDs defined in Section 7.1.2.
+
+   IP-compatible MEG_IDs for MPLS-TP sections at layer 0 are formed by
+   concatenating the two IF_IDs of the corresponding section using the
+   A1/Z9 ordering.  For example:
+
+      A1-IF_ID::Z9-IF_ID
+
+   Where the Section_MEG_ID needs to be globally unique, this is
+   accomplished by using globally unique Node_IDs as defined above.
+   Thus, a globally unique Section_MEG_ID becomes:
+
+      A1-{Global_ID::IF_ID}::Z9-{Global_ID::IF_ID}
+
+7.1.2.  MPLS-TP LSP MEG_IDs
+
+   A MEG pertains to a unique MPLS-TP LSP.  IP compatible MEG_IDs for
+   MPLS-TP LSPs are simply the corresponding LSP_IDs; however, the A1/Z9
+   ordering MUST be used.  For bidirectional co-routed LSPs, the format
+   of the LSP_ID is found in Section 5.2.1.  For associated
+   bidirectional LSPs, the format is in Section 5.2.2.
+
+
+
+
+
+
+
+
+Bocci, et al.                Standards Track                   [Page 13]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+   We note that while the two identifiers are syntactically identical,
+   they have different semantics.  This semantic difference needs to be
+   made clear.  For instance, if both an MPLS-TP LSP_ID and MPLS-TP LSP
+   MEG_IDs are to be encoded in TLVs, different types need to be
+   assigned for these two identifiers.
+
+7.1.3.  Pseudowire MEG_IDs
+
+   For Pseudowires, a MEG pertains to a single PW.  The IP-compatible
+   MEG_ID for a PW is simply the corresponding PW_Path_ID; however, the
+   A1/Z9 ordering MUST be used.  The PW_Path_ID is described in
+   Section 6.  We note that while the two identifiers are syntactically
+   identical, they have different semantics.  This semantic difference
+   needs to be made clear.  For instance, if both a PW_Path_ID and a
+   PW_MEG_ID are to be encoded in TLVs, different types need to be
+   assigned for these two identifiers.
+
+7.2.  Maintenance Entity Group End Point Identifiers
+
+7.2.1.  MPLS-TP Section MEP_IDs
+
+   IP-compatible MEP_IDs for MPLS-TP sections above layer 0 are their
+   MPLS-TP LSP_MEP_IDs.  See Section 7.2.2.
+
+   IP-compatible MEP_IDs for MPLS-TP sections at layer 0 are simply the
+   IF_IDs of each end of the section.  For example, for a section whose
+   MEG_ID is:
+
+      A1-IF_ID::Z9-IF_ID
+
+   the Section MEP_ID at A1 would be:
+
+      A1-IF_ID
+
+   and the Section MEP_ID at Z9 would be:
+
+      Z9-IF_ID.
+
+   Where the Section MEP_ID needs to be globally unique, this is
+   accomplished by using globally unique Node_IDs as defined above.
+   Thus, a globally unique Section MEP_ID becomes:
+
+      Global_ID::IF_ID.
+
+
+
+
+
+
+
+
+Bocci, et al.                Standards Track                   [Page 14]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+7.2.2.  MPLS-TP LSP_MEP_ID
+
+   In order to automatically generate MEP_IDs for MPLS-TP LSPs, we use
+   the elements of identification that are unique to an end point.  This
+   ensures that MEP_IDs are unique for all LSPs within an operator.
+   When Tunnels or LSPs cross operator boundaries, these are made unique
+   by pre-pending them with the operator's Global_ID.
+
+   The MPLS-TP LSP_MEP_ID is:
+
+      Node_ID::Tunnel_Num::LSP_Num
+
+   where the Node_ID is the node in which the MEP is located and
+   Tunnel_Num is the tunnel number unique to that node.  In the case of
+   co-routed bidirectional LSPs, the single LSP_Num is used at both
+   ends.  In the case of associated bidirectional LSPs, the LSP_Num is
+   the one unique to where the MEP resides.
+
+   In situations where global uniqueness is required, this becomes:
+
+      Global_ID::Node_ID::Tunnel_Num::LSP_Num
+
+7.2.3.  MEP_IDs for Pseudowires
+
+   Like MPLS-TP LSPs, Pseudowire end points (T-PEs) require MEP_IDs.  In
+   order to automatically generate MEP_IDs for PWs, we simply use the
+   AGI plus the AII associated with that end of the PW.  Thus, a MEP_ID
+   for a Pseudowire T-PE takes the form:
+
+      AGI::Global_ID::Node_ID::AC_ID
+
+   where the Node_ID is the node in which the MEP is located and the
+   AC_ID is the AC_ID of the Pseudowire at that node.
+
+7.3.  Maintenance Entity Group Intermediate Point Identifiers
+
+   For a MIP that is associated with a particular interface, we simply
+   use the IF_ID (see Section 4) of the interfaces that are cross-
+   connected.  This allows MIPs to be independently identified in one
+   node where a per-interface MIP model is used.  If only a per-node MIP
+   model is used, then one MIP is configured.  In this case, the MIP_ID
+   is formed using the Node_ID and an IF_Num of 0.
+
+8.  Security Considerations
+
+   This document describes an information model and, as such, does not
+   introduce security concerns.  Protocol specifications that describe
+   use of this information model, however, may introduce security risks
+
+
+
+Bocci, et al.                Standards Track                   [Page 15]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+   and concerns about authentication of participants.  For this reason,
+   the writers of protocol specifications for the purpose of describing
+   implementation of this information model need to describe security
+   and authentication concerns that may be raised by the particular
+   mechanisms defined and how those concerns may be addressed.
+
+   Uniqueness of the identifiers from this document is guaranteed by the
+   assigner (e.g., a Global_ID is unique based on the assignment of ASNs
+   from IANA and both a Node_ID and an IF_Num are unique based on the
+   assignment by an operator).  Failure by an assigner to use unique
+   values within the specified scoping for any of the identifiers
+   defined herein could result in operational problems.  For example, a
+   non-unique MEP value could result in failure to detect a mis-merged
+   LSP.
+
+   Protocol specifications that utilize the identifiers defined herein
+   need to consider the implications of guessable identifiers and, where
+   there is a security implication, SHOULD give advice on how to make
+   identifiers less guessable.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and
+         G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
+         RFC 3209, December 2001.
+
+   [3]   Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment
+         Individual Identifier (AII) Types for Aggregation", RFC 5003,
+         September 2007.
+
+   [4]   Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
+         Signaling Functional Description", RFC 3471, January 2003.
+
+   [5]   Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
+         Signaling Resource ReserVation Protocol-Traffic Engineering
+         (RSVP-TE) Extensions", RFC 3473, January 2003.
+
+   [6]   Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron,
+         "Pseudowire Setup and Maintenance Using the Label Distribution
+         Protocol (LDP)", RFC 4447, April 2006.
+
+
+
+
+
+
+Bocci, et al.                Standards Track                   [Page 16]
+
+RFC 6370                   MPLS-TP Identifiers            September 2011
+
+
+9.2.  Informative References
+
+   [7]   Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
+         S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
+         September 2009.
+
+   [8]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
+         RFC 2863, June 2000.
+
+   [9]   Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A
+         Framework for MPLS in Transport Networks", RFC 5921, July 2010.
+
+   [10]  Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile
+         Data Plane Architecture", RFC 5960, August 2010.
+
+Authors' Addresses
+
+   Matthew Bocci
+   Alcatel-Lucent
+   Voyager Place, Shoppenhangers Road
+   Maidenhead, Berks  SL6 2PJ
+   UK
+
+   EMail: matthew.bocci@alcatel-lucent.com
+
+
+   George Swallow
+   Cisco
+
+   EMail: swallow@cisco.com
+
+
+   Eric Gray
+   Ericsson
+   900 Chelmsford Street
+   Lowell, Massachussetts  01851-8100
+
+   EMail: eric.gray@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al.                Standards Track                   [Page 17]
+