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

Versions: 00 01 02 03 04 05

MPLS Working Group                                              F. Zhang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                      September 16, 2011
Expires: March 19, 2012


         RSVP-TE Extentions to Exchange MPLS-TP Tunnel Numbers
           draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00

Abstract

   The MPLS Transport Profile (MPLS-TP) identifiers document
   [I-D.ietf-mpls-tp-identifiers] introduce two tunnel numbers, A1-
   Tunnel_Num and Z9-Tunnel_Num, which allow a compact format for
   Maintenance Entity Point Identifier (MEP_ID).  For some Operation,
   Administration and Maintenance (OAM) functions, such as Connectivity
   Verification (CV) [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP_ID MUST be
   inserted in the OAM packets, so that the peer endpoint can compare
   the received and expected MEP_IDs to judge whether there is a
   mismatch, which means that the two MEP nodes need to pre-store each
   other's MEP_IDs.

   The specification of setting up co-routed bidirectional LSP is
   described in the document [RFC3473], which does not introduce the
   locally configured tunnel number on the tunnel endpoint.  This
   document defines the Connection object to exchange the tunnel
   numbers.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 19, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the



Zhang                    Expires March 19, 2012                 [Page 1]


Internet-Draft      RSVP-TE Extentions for Tunnel-Num     September 2011


   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
   2.  Conventions used in this document . . . . . . . . . . . . . . . 3
   3.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Connection Object . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative references  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6

























Zhang                    Expires March 19, 2012                 [Page 2]


Internet-Draft      RSVP-TE Extentions for Tunnel-Num     September 2011


1.  Introduction

   The MPLS Transport Profile (MPLS-TP) identifiers document
   [I-D.ietf-mpls-tp-identifiers] introduce two tunnel numbers, A1-
   Tunnel_Num and Z9-Tunnel_Num, which are locally assigned and allow a
   compact format for Maintenance Entity Point Identifier (MEP_ID).  For
   a co-routed bidirectional LSP, the format of A1-MEP_ID is A1-
   Node_ID::A1-Tunnel_Num::LSP_Num, and the format of Z9-MEP_ID is Z9-
   Node_ID::Z9-Tunnel_Num::LSP_Num. In order to realize some Operation,
   Administration and Maintenance (OAM) functions, such as Connectivity
   Verification (CV) [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP-ID MUST be
   inserted in the OAM packets, in this way the peer endpoint can
   compare the received and expected MEP-IDs to judge whether there is a
   mismatch.  Hence, the two MEP nodes must pre-store each other's MEP-
   IDs before sending the CV packets.

   Although the exchange of MEP_IDs can be accomplished by Network
   Management System (NMS) if it is deployed, it is still complex when
   the LSPs cross different adiminstration domains, which needs the
   cooperation of NMSs.  So when the LSPs are set up by control plane,
   Resource ReserVation Protocol Traffic Engnieering (RSVP-TE) signaling
   will be more suitable to realize the exchange of MEP_IDs.

   The specification of setting up co-routed bidirectional LSP is
   described in the document [RFC3473], which does not introduce the
   locally configured tunnel number on the tunnel endpoint.  This
   document defines the Connection object to exchange the tunnel
   numbers.


2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Operation

   MPLS-TP co-routed bidirectional LSPs can be deloyed across one or
   more administration domains, and NMS may exist in some administration
   domains, which knows the tunnel spaces of every node in it's
   responsible domain.  Consider that LSP1 is initialized at A1 node
   with Connection object inserted in LSP1's Path message , the
   following modes may happend.

   Modes 1: L bit is set, and the Z9-Tunnel_Num is designated in the
   "Destination Tunnel Num" field.  If the Z9 node finds that this



Zhang                    Expires March 19, 2012                 [Page 3]


Internet-Draft      RSVP-TE Extentions for Tunnel-Num     September 2011


   tunnel number is occupied, or it can not be used because of some
   local policies, a PathErr message must be sent with "Unavailable
   tunnel number" error.  Otherwise, the designated tunnel number must
   be adopted, and the Connection object may be inserted in the Resv
   message without any change.

   Modes 2: L bit is not set, and a recommended Z9-Tunnel_Num may be
   filled in the "Destination Tunnel Num" field.  If the Z9 node finds
   that the recommended value can be used, the Connection object must be
   inserted in the Resv message without any change; if the recommended
   value can not be used or the "Destination Tunnel Num" field is empty,
   a new tunnel number will be allocated and filled into the Connection
   object that must be inserted in the Resv message.

   Each mode has its own pros and cons and how to determine the right
   mode for a specific network mainly depends on the operators'
   preference.  For example, for the operators who are used to operate
   traditional transport network and familiar with the Transport-Centric
   operational model may prefer mode 1.  The second mode is more
   suitable for the operators who are familiar with the operation and
   maintenance of IP/MPLS network, or the MPLS-TP LSPs cross multiple
   administration domains.


4.  Connection Object

   The format of Connection Object (Class-Num of the form 11bbbbbb with
   value = TBA, C-Type = TBA) is as 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             | Class-Num(TBA)|  C-Type (TBA) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |L|            Reserverd        |       Destination Tunnel Num  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                             Connection Object











Zhang                    Expires March 19, 2012                 [Page 4]


Internet-Draft      RSVP-TE Extentions for Tunnel-Num     September 2011


   L

       The L bit is set if the initiating node enforces the peer
       endpoint to configure the value carried in the field of
       "Destination Tunnle Num".

       If the bit is not set, the peer endpoint firstly tries to
       use the recommended tunnel number; it can use any other
           unoccupied tunnnel numbers when the recommended tunnel
           number is unavailable.

   Reserverd

       Must be set to 0 on transmit and ignored on receive.

   Destination Tunnel Num

       If the L bit is set, it indicates that the peer endpoint
           must configure the value carried in this field.

       If the L bit is not set, this field can be empty or filled
           by the recommended value.


   The Connection object may appear in Path or Resv message, and a
   midpoint that does not support this object is required to pass it on
   unaltered, as indicated by the C-Num and the rules defined in
   [RFC2205].


5.  IANA Considerations

   TBD.


6.  Security Considerations

   TBD.


7.  Acknowledgement

   This document was prepared based on the discussion with George
   Swallow, valuable comments and input was also received from
   Venkatesan Mahalingam and Muliu Tao.


8.  References



Zhang                    Expires March 19, 2012                 [Page 5]


Internet-Draft      RSVP-TE Extentions for Tunnel-Num     September 2011


8.1.  Normative references

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

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

8.2.  Informative References

   [I-D.ietf-mpls-tp-cc-cv-rdi]
              Allan, D., Swallow, G., and J. Drake, "Proactive
              Connectivity Verification, Continuity Check and Remote
              Defect indication for MPLS Transport Profile",
              draft-ietf-mpls-tp-cc-cv-rdi-06 (work in progress),
              August 2011.

   [I-D.ietf-mpls-tp-identifiers]
              Bocci, M., Swallow, G., and E. Gray, "MPLS-TP
              Identifiers", draft-ietf-mpls-tp-identifiers-07 (work in
              progress), July 2011.


Author's Address

   Fei Zhang
   ZTE Corporation

   Email: zhang.fei3@zte.com.cn


   Xiao Bao
   ZTE Corporation

   Email: bao.xiao1@zte.com.cn











Zhang                    Expires March 19, 2012                 [Page 6]


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