Internet DRAFT - draft-helvoort-mpls-tp-rosetta-stone

draft-helvoort-mpls-tp-rosetta-stone





MPLS Working Group                                H. van Helvoort (Ed) 
Internet Draft                                     Huawei Technologies 
Intended status: Informational 
Expires: September 2009                              L. Andersson (Ed) 
                                                              Redback 
 
                                                      N. Sprecher (Ed) 
                                                Nokia Siemens Networks 
 
                                                         March 3, 2009 
 
                                      
        A Thesaurus for the Terminology used in Multiprotocol Label 
       Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's 
                    Transport Network Recommendations. 
                  draft-helvoort-mpls-tp-rosetta-stone-00 


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 September 1, 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 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.
 
van Helvoort et al.    Expires September 2009                 [Page 1] 

Internet-Draft        <MPLS-TP Rosetta Stone>           February 2009 
                                             

 

Abstract 

   MPLS-TP is based on a profile of the MPLS and PW procedures as 
   specified in the MPLS-TE and (MS-)PW architectures developed by the 
   IETF.  The ITU-T has specified a Transport Network architecture. 

   This document provides a thesaurus for the interpretation of MPLS-TP 
   terminology within the context of the ITU-T Transport Network 
   recommendations. 

   It is important to note that MPLS-TP is applicable in a wider set of 
   contexts than just Transport Networks.  The definitions presented in 
   this document do not provide exclusive nor complete interpretations 
   of MPLS-TP concepts.  This document simply allows the MPLS-TP terms 
   to be applied within the Transport Network context. 

    

Table of Contents 
 
   1.  Introduction 3 
      1.1.  Contributing Authors 4 
      1.2.  Abbreviations 4 
   2.  Terminology  4 
      2.1.  MPLS-TP Terminology Sources  4 
      2.2.  ITU-T Transport Network Terminology Sources 4 
      2.3.  Common Terminology Sources 5 
   3.  Thesaurus 5 
      3.1.  Associated bidirectional path:  5 
      3.2.  Bidirectional path:  5 
      3.3.  Concatenated Segment:  5 
      3.4.  Co-routed bidirectional path:   5 
      3.5.  Domain:  5 
      3.6.  Layer network: 6 
      3.7.  Link:   6 
      3.8.  Logical Ring: 6 
      3.9.  Path:   6 
      3.10.  Physical Ring:  6 
      3.11.  Ring Topology:  6 
      3.12.  Section:  7 
      3.13.  Segment:  7 
      3.14.  Service layer:  7 
      3.15.  Span:  7 
      3.16.  Sublayer:  7 
      3.17.  Tandem Connection:  7 
 
 
van Helvoort et al.    Expires September 2009                 [Page 2] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

      3.18.  Transport path:  8 
      3.19.  Transport path layer:  8 
      3.20.  Transport service layer:  8 
      3.21.  Transmission media layer:   8 
      3.22.  Unidirectional path:  8 
      3.23.  Failure:  8 
      3.24.  Fault: 9 
      3.25.  Defect: 9 
      3.26.  MPLS Transport Profile (MPLS-TP): 9 
      3.27.  MPLS Section: 9 
      3.28.  MPLS-TP NE:  9 
      3.29.  MPLS-TP network:   9 
      3.30.  Equipment Management Function (EMF):  9 
      3.31.  Data Communication Network (DCN):  10 
      3.32.  Communication Channel (CC): 10 
      3.33.  Embedded Communication Channel (ECC):   10 
      3.34.  Management Communication Channel (MCC):  10 
      3.35.  Management Communication Network (MCN): 10 
      3.36.  Signaling Communication Channel (SCC):  10 
      3.37.  Signaling Communication Network (SCN):  10 
      3.38.  Operations System (OS):  10 
      3.39.  Maintenance Entity 11 
      3.40.  Maintenance End Points (MEPs)  11 
      3.41.  Maintenance Intermediate Points (MIPs)  12 
      3.42.  Server MEPs  12 
   4.  Guidance on the Application of this Thesaurus 16 
   5.  Management Considerations 17 
   6.  Security Considerations  17 
   7.  IANA Considerations 17 
   8.  Acknowledgments 17 
   9.  References 17 
      9.1.  Normative References 17 
      9.2.  Informative References 18 
    Authors' Addresses 18 
    Contributing Authors' Addresses 19 
    Intellectual Property Statement 19 
    Disclaimer of Validity 19


1.   Introduction 

   Multiprotocol Label Switching -                                    - Transport Profile (MPLS-TP) has been 
   developed by the IETF to facilitate the Operation, Administration 
   and Management of Label Switched Paths (LSPs) in a Transport Network 
   environment as defined by the ITU-T. 


 
 
van Helvoort et al.    Expires September 2009                 [Page 3] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

   The ITU-T has specified a Transport Network architecture for the 
   transfer of signals from different technologies.  This architecture 
   forms the basis of many Recommendations within the ITU-T. 

   Because of the difference in historic background of MPLS, and 
   inherently MPLS-TP (the Internet) and the Transport Network (ITU 
   telecommunication Sector), the terminology used is different. 

   This document provides a thesaurus for the interpretation of ITU-T 
   Transport Network terminology within the context of the MPLS-TP.    
   This allows MPLS-TP documents to be generally understood by those 
   familiar with MPLS RFCs.  The definitions presented in this document 
   do not provide exclusive or complete interpretations of the ITU-T 
   Transport Network concepts. 

1.1.  Contributing Authors 

   Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven 
   Levrau, Dinesh Mohan, Vincenzo Sestito, Nurit Sprecher, Huub van 
   Helvoort, Martin Vigoureux, Yaacov Weingarten 

1.2.  Abbreviations 

   ME   Maintenance Entity 

   MEP  Maintenance End Point 

   MIP  Maintenance Intermediate Point 

    

2.   Terminology 

   Throughout this document, angle brackets ("<" and ">") are used to 
   indicate that the term is used by both IETF and ITU-T but has a 
   different definition. The bracketed term is the IETF term. 

   [editor: check all terms used that this applies to, TBD] 

2.1.  MPLS-TP Terminology Sources 

   MPLS-TP terminology is principally defined in [RFC....].  Other 
   documents provide further key definitions including [RFC....], and 
   [RFC....]. 



 
 
van Helvoort et al.    Expires September 2009                 [Page 4] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

2.2.  ITU-T Transport Network Terminology Sources 

   The ITU-T Transport Network is specified in a number of 
   recommendations:  generic functional architectures and requirements 
   are specified in G.805 [ITU-T_G.805], G.806 [ITU-T_G.806], and G.872 
   [ITU-T_G.872].  G.8101 [ITU-T_G.8101] contains an overview of the 
   Terms and Definitions for transport MPLS. 

2.3.  Common Terminology Sources 

   The work in this document builds on the shared view of MPLS 
   requirements. 

    

3.   Thesaurus 

   From: draft-ietf-mpls-tp-requirements-04 [1] 

3.1.  Associated bidirectional path:  

   A path that supports traffic flow in both directions but which is 
   constructed from a pair of unidirectional paths (one for each 
   direction) which are associated with one another at the path's 
   ingress/egress points.  The forward and backward directions may or 
   may not follow the same route (links and nodes) across the network. 

3.2.  Bidirectional path:  

   A path where the forward and backward directions follow the same 
   route (links and nodes) across the network. 

3.3.  Concatenated Segment: 

   A serial-compound link connection as defined in G.805 [ITU-T_G.805].  
   A concatenated segment is a contiguous part of an LSP or multi-
   segment PW that comprises a set of segments and their 
   interconnecting nodes in sequence. 

3.4.  Co-routed bidirectional path:  

   A bidirectional path where the forward and backward directions 
   follow the same route (links and nodes) across its layer network. 




 
 
van Helvoort et al.    Expires September 2009                 [Page 5] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

3.5.  Domain:  

   A domain represents a collection of entities (for example   network 
   elements) that are grouped for a particular purpose, examples of 
   which are administrative and/or managerial responsibilities, trust 
   relationships, addressing schemes, infrastructure capabilities, 
   aggregation, survivability techniques, distributions of control 
   functionality, etc.  Examples of such domains include IGP areas and 
   Autonomous Systems. 

3.6.  Layer network: 

   Layer network is defined in G.805 [ITU-T_G.805].  A layer network 
   provides for the transfer of client information and independent 
   operation of the client OAM.  A Layer Network may be described in a 
   service context as follows: one layer network may provide a 
   (transport) service to higher client layer network and may, in turn, 
   be a client to a lower layer network.  A layer network is a logical 
   construction somewhat independent of arrangement or composition of 
   physical network elements.  A particular physical network element 
   may topologically belong to more than one layer network, depending 
   on the actions it takes on the encapsulation(s) associated with the 
   logical layers (e.g. the label stack), and thus could be modeled as 
   multiple logical elements.  A layer network may consist of zero or 
   more sublayers.  For additional explanation of how layer networks 
   relate to the OSI concept of layering see Appendix I of Y.2611 [ITU-
   T_Y.2611]. 

3.7.  Link:  

   A physical or logical connection between a pair of LSRs that are 
   adjacent at the (sub)layer network under consideration.  A link may 
   carry zero, one or more LSPs or PWs.  A packet entering a link will 
   emerge with the same label stack entry values. 

   A link as defined in G.805 [ITU-T_G.805] is used to describe a fixed 
   relationship between two ports. 

3.8.  Logical Ring: 

   An MPLS-TP logical ring is constructed from a set of LSRs and 
   logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 
   pseudowires) and physical data links that form a ring topology. 

3.9.  Path:  

   See Transport path. 
 
 
van Helvoort et al.    Expires September 2009                 [Page 6] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

3.10.   Physical Ring:  

   An MPLS-TP physical ring is constructed from a set of LSRs and 
   physical data links that form a ring topology. 

3.11.   Ring Topology:  

   In an MPLS-TP ring topology each LSR is connected to exactly two 
   other LSRs, each via a single point-to-point bidirectional MPLS-TP 
   capable data link.  A ring may also be constructed from only two 
   LSRs where there are also exactly two links.  Rings may be connected 
   to other LSRs to form a larger network.  Traffic originating or 
   terminating outside the ring may be carried over the ring.  Client 
   network nodes (such as CEs) may be connected directly to an LSR in 
   the ring. 

3.12.   Section:  

   A section is a server layer (which may be MPLS-TP or a different 
   technology) which provides for encapsulation and OAM of a MPLS-TP 
   transport path client layer.  A section layer may provide for 
   aggregation of multiple MPLS-TP clients.  Note that G.805 [ITU-
   T_G.805] defines the section layer as one of the two layer    
   networks in a transmission media layer network.  The other layer    
   network is the physical media layer network. 

3.13.   Segment: 

   A link connection as defined in G.805 [ITU-T_G.805].  A segment is 
   the part of an LSP that traverses a single link or the part of a PW 
   that traverses a single link (i.e. that connects a pair of adjacent 
   {S|T}-PEs). 

3.14.   Service layer:  

   A layer network in which transport paths are used to carry a 
   customer's (individual or bundled) service (may be point-to-point, 
   point-to-multipoint or multipoint-to-multipoint services). 

3.15.   Span: 

   A span is synonymous with a link. 

3.16.   Sublayer:  

   Sublayer is defined in G.805 [ITU-T_G.805].  The distinction between 
   a layer network and a sublayer is that a sublayer is not directly 
 
 
van Helvoort et al.    Expires September 2009                 [Page 7] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

   accessible to clients outside of its encapsulating layer network and 
   offers no direct transport service for a higher layer (client) 
   network. 

3.17.   Tandem Connection:  

   A tandem connection is an arbitrary part of a transport path that 
   can be monitored (via OAM) independently from the end-to-end 
   monitoring (OAM).  It may be a monitored segment, a monitored 
   concatenated segment or any other monitored ordered sequence of 
   contiguous hops and/or segments (and their interconnecting nodes) of 
   a transport path. 

3.18.   Transport path:  

   A network connection as defined in G.805 [ITU-T_G.805].  In an MPLS-
   TP environment a transport path corresponds to an LSP or a PW. 

3.19.   Transport path layer:  

   A layer network which provides point-to-point or point-to-multipoint 
   transport paths which are used to carry a higher (client) layer 
   network or aggregates of higher (client) layer networks, for example 
   the transport service layer.  It provides for independent OAM (of 
   the client OAM) in the transport of the clients. 

3.20.   Transport service layer:  

   A layer network in which transport paths are used to carry a 
   customer's (individual or bundled) service (may be point-to-point, 
   point-to-multipoint or multipoint-to-multipoint services). 

3.21.   Transmission media layer:  

   A layer network which provides sections (two-port point-to-point 
   connections) to carry the aggregate of network transport path or 
   network service layers on various physical media. 

3.22.   Unidirectional path:  

   A path that supports traffic flow in only one direction. 

   === 

   from: draft-ietf-mpls-tp-oam-requirements-00 [2] 


 
 
van Helvoort et al.    Expires September 2009                 [Page 8] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

3.23.   Failure:  

   [editor: this is not in [2] BUT added fro completeness] 

   The fault cause persisted long enough to consider the ability of an 
   item to perform a required function to be terminated. The item may 
   be considered as failed; a fault has now been detected.  See also 
   G.806 [ITU-T_.G.806]. 

3.24.   Fault: 

   The inability of a function to perform a required action.  This does 
   not include an inability due to preventive maintenance, lack of 
   external resources, or planned actions.  See also G.806 [ITU-
   T_G.806].  

3.25.   Defect: 

   The situation for which density of anomalies has reached a level 
   where the ability to perform a required function has been 
   interrupted. Defects are used as input for PM, the control of 
   consequent actions, and the determination of fault cause. See also 
   G.806 [ITU-T_G.806].  

3.26.   MPLS Transport Profile (MPLS-TP): 

   The set of MPLS functions used to support packet transport services 
   and network operations.  

3.27.   MPLS Section: 

   A network segment between two LSRs that are immediately adjacent at 
   the MPLS layer.  

   == 

   From: draft-ietf-mpls-tp-framework-00 [3] 

   == 

   From: draft-gray-mpls-tp-nm-req-03 [4] 

3.28.   MPLS-TP NE: 

   A network element (NE) that supports MPLS-TP functions. 


 
 
van Helvoort et al.    Expires September 2009                 [Page 9] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

3.29.   MPLS-TP network:  

   A network in which MPLS-TP NEs are deployed   

3.30.   Equipment Management Function (EMF):  

   The management functions within an NE. See G.7710 [ITU-T_G.7710].  

3.31.   Data Communication Network (DCN):  

   A network that supports Layer 1 (physical layer), Layer 2 (data-link 
   layer), and Layer 3 (network layer) functionality for distributed 
   management communications related to the management plane, for 
   distributed signaling communications related to the control plane, 
   and other operations communications (e.g., order-wire/voice 
   communications, software downloads, etc.).  

3.32.   Communication Channel (CC): 

   A logical channel between network elements (NEs) that can be used - 
   e.g. - for management plane application or control plane 
   applications. The physical channel supporting the CC is technology 
   specific.  See [4] APPENDIX A   

3.33.   Embedded Communication Channel (ECC):  

   A logical operations channel between network elements (NEs) that can 
   be utilized by multiple applications (e.g., management plane 
   applications, control plane applications, etc.). The physical 
   channel supporting the ECC is technology specific. An example of 
   physical channels supporting the ECC is a DCC channel within SDH.  

3.34.   Management Communication Channel (MCC):  

   A CC dedicated for management plane communications.  

3.35.   Management Communication Network (MCN): 

   A DCN supporting management plane communication is referred to as a 
   Management Communication Network (MCN).  

3.36.   Signaling Communication Channel (SCC):  

   A CC dedicated for control plane communications. The SCC may be used 
   for GMPLS/ASON signaling and/or other control plane messages (e.g., 
   routing messages).   

 
 
van Helvoort et al.    Expires September 2009                [Page 10] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

3.37.   Signaling Communication Network (SCN):  

   A DCN supporting control plane communication is referred to as a 
   Signaling Communication Network (SCN).  

3.38.   Operations System (OS):  

   A system that performs the functions that support processing of 
   information related to operations, administration, maintenance, and 
   provisioning (OAM&P) for the networks, including surveillance and 
   testing functions to support customer access maintenance. 

   == 

   From: draft-busi-mpls-tp-oam-framework-00 [5] 

   MPLS Section: [editor: see 3.27] 

   OAM flow: to be added in a future revision of this document.  

   Tandem Connection: [editor: see 3.17] 

3.39.   Maintenance Entity 

   A Maintenance Entity can be viewed as the association of two (or 
   more) Maintenance End Points (MEPs), that should be configured and 
   managed in order to bound the OAM responsibilities of an OAM flow 
   [editor: definition?] across a network or sub-network, i.e. a 
   transport path or segment, in the specific layer network that is 
   being monitored and managed. 

   A Maintenance Entity may be defined to monitor and manage bi-
   directional or unidirectional point-to-point connectivity or point-
   to-multipoint connectivity in an MPLS-TP layer network.   

   [editor: should the following be included?] 

   Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity 
   (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can 
   be MIPs. In the case of Tandem Connection Maintenance Entity 
   (defined below), LSRs and S-PEs can be either MEPs or MIPs.  

   The following properties apply to all MPLS-TP MEs: 

   o OAM entities can be nested but not overlapped. 

   o Each OAM flow is associated to a unique Maintenance Entity. 
 
 
van Helvoort et al.    Expires September 2009                [Page 11] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

   o OAM packets are subject to the same forwarding treatment as the 
      data traffic, but they are distinct from the data traffic.  

3.40.   Maintenance End Points (MEPs) 

   Maintenance End Points (MEPs) are the end points of a pre-configured 
   (through the management or control planes) ME.  MEPs are responsible 
   for activating and controlling all of the OAM functionality for the 
   ME. A MEP may initiate an OAM packet to be transferred to its 
   corresponding MEP, or to an intermediate MIP that is part of the ME. 

   A MEP terminates all the OAM packets that it receives corresponding 
   to its ME and does not forward them further along the path.  

   All OAM packets coming to a MEP source are tunnelled via label 
   stacking and are not processed within the ME as they belong either 
   to the client network layers or to an higher TCM level.  

   A MEP in a tandem connection is not coincident with the termination 
   of the MPLS-TP transport path (LSP or PW), though it can monitor its 
   connectivity (e.g. count packets). A MEP of an MPLS-TP network 
   transport path is coincident with transport path termination and 
   monitors its connectivity (e.g. count packets).  

   MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer 
   network.  

3.41.   Maintenance Intermediate Points (MIPs) 

   A Maintenance Intermediate Point (MIP) is a point between the two 
   MEPs in an ME and is capable of responding to some OAM packets and 
   forwarding all OAM packets while ensuring fate sharing with data 
   plane packets.  A MIP responds only to OAM packets that are sent on 
   the ME it belongs to and that are addressed to the MIP, it does not 
   initiate OAM messages. 

3.42.   Server MEPs 

   A server MEP is a MEP of an ME that is defined in a layer network 
   below the MPLS-TP layer network being referenced. A server MEP 
   coincides with either a MIP or a MEP in the client (MPLS-TP) layer 
   network.  

   For example, a server MEP can be either:  



 
 
van Helvoort et al.    Expires September 2009                [Page 12] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

   . A termination point of a physical link (e.g. 802.3), an SDH VC or 
     OTH ODU for the MPLS-TP Section layer network, defined in [5] 
     section 3.1.; 

   . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [5] section 
     3.2.; 

   . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [5] section 3.4.;  

   . An MPLS-TP TCM MEP for higher-level TCMs, defined in [5] sections 
     3.3. and 3.5. 

   The server MEP can run appropriate OAM functions for fault 
   detection, and notifies a fault indication to the MPLS-TP layer 
   network.   

   [editor: the following are definitions from G.8101 which should be 
   defined only if they will cause misunderstanding. It is not usefull 
   to define them if the definition is the same in IETF and ITU-T, TBD] 

===== ITU-T Rec. G.8101/Y.1355 (12/2006) =====  

   3.1 access point  

   3.2 adapted information  

   3.3 characteristic information  

   3.4 client/server relationship  

   3.5 connection  

   3.6 connection point  

   3.9 forward direction  

   3.12 link connection  

   3.13 matrix  

   3.14 network  

   3.15 network connection  

   3.16 network operator  

   3.17 port  
 
 
van Helvoort et al.    Expires September 2009                [Page 13] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

   3.18 reference point  

   3.19 service provider  

   3.20 subnetwork  

   3.21 subnetwork connection  

   3.22 termination connection point  

   3.23 trail  

   3.24 trail termination  

   3.25 trail termination point  

   3.26 transport  

   3.27 transport entity  

   3.28 transport processing function  

   3.29 unidirectional connection  

   3.30 unidirectional trail  

   3.31 Z layer  

   Transport MPLS (T-MPLS) Recommendations uses the following terms 
   defined in ITU-T Rec. G.809:  

   3.33 access point  

   3.34 adaptation  

   3.35 adapted information  

   3.36 characteristic information  

   3.37 client/server relationship  

   3.50 network  

   3.52 port  

   3.53 reference point  

 
 
van Helvoort et al.    Expires September 2009                [Page 14] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

   3.56 traffic unit  

   3.57 transport  

   3.58 transport entity  

   Transport MPLS (T-MPLS) Recommendations uses the following term 
   defined in ITU-T Rec. G.8010/Y.1306:  

   3.59 point-to-point Ethernet connection  

   Transport MPLS (T-MPLS) Recommendations uses the following terms 
   defined in ITU-T Rec. Y.1711:  

   3.60 backward direction  

   3.62 client/server (relationship between layer networks)  

   3.63 failure 

   3.64 forward direction  

   3.65 user-plane  

   Transport MPLS (T-MPLS) Recommendations uses the following terms 
   defined in ITU-T Rec. Y.1720:  

   3.66 1+1 protection  

   3.67 1:1 protection   

   3.68 bidirectional protection switching  

   3.69 bridge  

   3.71 extra traffic   

   3.72 failure 

   3.73 forced switch for working LSP  

   3.74 hold-off time  

   3.75 manual switch  

   3.76 MPLS protection domain  

 
 
van Helvoort et al.    Expires September 2009                [Page 15] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

   3.77 non-revertive protection switching  

   3.78 no request  

   3.79 packet 1+1 protection  

   3.80 path switch LSR  

   3.81 path merge LSR  

   3.82 protection LSP  

   3.83 protection switching  

   3.84 rerouting  

   3.85 revertive protection switching  

   3.86 selector  

   3.87 shared mesh protection  

   3.88 Shared Risk Group (SRG)  

   3.89 sink of the protection domain  

   3.90 source of the protection domain  

   3.91 unidirectional protection switching  

   3.92 wait to restore  

   3.93 wait to restore timer  

   3.94 working LSP  

   Transport MPLS (T-MPLS) Recommendations uses the following terms 
   defined in ITU-T Rec. Y.1731:  

   3.95 in-service OAM  

===== end of ITU-T Rec. G.8101/Y.1355 (12/2006) =====  

 



 
 
van Helvoort et al.    Expires September 2009                [Page 16] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

4.   Guidance on the Application of this Thesaurus 

   As discussed in the introduction to this document, this thesaurus is 
   intended to bring the concepts and terms associated with MPLS-TP 
   into the context of the ITU-T's Transport Network architecture.  
   Thus, it should help those familiar with MPLS to see how they may 
   use the features and functions of the Transport Network in order to 
   meet the requirements of MPLS-TP. 

   This lexicography should not be used in order to obtain or derive 
   definitive definitions of GMPLS terms.  To obtain definitions of 
   GMPLS terms that are applicable across all GMPLS architectural 
   models, the reader should refer to the RFCs listed in the references 
   sections of this document.  [RFC3945] provides an overview of the 
   GMPLS architecture and should be read first. 

5.   Management Considerations 

   The MPLS-TP based network requires management. The MPLS-TP 
   specifications include considerable efforts to provide operator 
   control and monitoring, as well as Operations and Management 
   (OAM)functionality. 

   These concepts are, however, out of scope of this document. 

6.   Security Considerations 

   Security is also a significant requirement of MPLS-TP. 

   However, this informational document is intended only to  provide a 
   lexicography, and the security concerns are, therefore, out of 
   scope. 

7.   IANA Considerations 

   To be incorporated in a future revision of this document 

   <<TBA>> 

8.   Acknowledgments 

   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 in ITU-T) involved in the definition and 
   specification of MPLS Transport Profile. 


 
 
van Helvoort et al.    Expires September 2009                [Page 17] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

9.   References 

9.1.  Normative References 

   [1]  B. Niven-Jenkins, et al., ''MPLS-TP Requirements'', draft-ietf-
         mpls-mpls-tp-requirements, november 2008  

   [2]  Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 
         MPLS Transport Networks", draft-vigoureux-mpls-tp-oam-
         requirements, november 2008  

   [3]  Bocci, M., Bryant, S., "A Framework for MPLS in Transport 
         Networks'', draft-ietf-mpls-tp-framework, november 2008 

   [4]  Gray, E., Mansfield, S., et al., ''MPLS TP Network Management 
         Requirements'', draft-gray-mpls-tp-nm-req, november 2008 

   [5]  Busi, I., Niven-Jenkins, B., et al., ''MPLS-TP OAM Framework 
         and Overview'', draft-busi-mpls-tp-oam-framework, november 2008  

                                                      

9.2.  Informative References 

   For information on the availability of the following documents, 
   please see http://www.itu.int 

   [6]  [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), 
         Terms and definitions for transport MPLS. 

   [7]  [ITU-T_G.805] ITU-T Recommendation G.805 (2000), Generic 
         functional architecture of transport networks. 

   [8]  [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), 
         Characteristics of transport equipment -                                                   - Description 
         methodology and generic functionality. 

   [9]  [ITU-T_Y.1711] ITU-T Recommendation Y.1711 (10/2005) Operation 
         & Maintenance mechanism for MPLS networks. 

   [10] [ITU-T_Y.1720] ITU-T Recommendation Y.1720 (02/2008), 
         Protection switching for MPLS networks. 

   [11] [ITU-T_Y.1731] ITU-T Recommendation Y.1731 (02/2008), OAM 
         functions and mechanisms for Ethernet based networks. 


 
 
van Helvoort et al.    Expires September 2009                [Page 18] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009 
                                             

   [12] [ITU-T_G.872] ITU-T Recommendation G.872 (2001), Architecture 
         of optical transport networks. 

   [13] [ITU-T_G.7710] ITU-T Recommendation G.7710 (), 

   [14] [ITU_Y.2611] ITU-T Recommendation Y.2611 (), 

                                                      

Authors' Addresses 

   Huub van Helvoort (editor) 
   Huawei Technologies 
   Email: hhelvoort@huawei.com 
    
   Loa Andersson (editor) 
   Redback 
   Email: loa@pi.nu 

   Nurit Sprecher (editor) 
   Nokia Siemens Networks 
   Email: nurit.sprecher@nsn.com 
 

 

Contributing Authors' Addresses 

    
 

    















 
 
van Helvoort et al.    Expires September 2009                [Page 19] 

Internet-Draft          MPLS-TP Rosetta Stone            February 2009