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

Versions: (draft-zhang-ccamp-srlg-fa-configuration) 00 01 02 03 04 05 06 07 08 09 draft-ietf-teas-rsvp-te-srlg-collect

Network Working Group                                      F. Zhang, Ed.
Internet-Draft                                                     D. Li
Intended status: Standards Track                                  Huawei
Expires: April 25, 2013                         O. Gonzalez de Dios, Ed.
                                                          Telefonica I+D
                                                             C. Margaria
                                                  Nokia Siemens Networks
                                                              M. Hartley
                                                                   Cisco
                                                        October 22, 2012


           RSVP-TE Extensions for Collecting SRLG Information
                draft-ietf-ccamp-rsvp-te-srlg-collect-01

Abstract

   This document provides extensions for the Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) to support automatic
   collection of Shared Risk Link Group (SRLG) Information for the TE
   link formed by a LSP.

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 April 25, 2013.

Copyright Notice

   Copyright (c) 2012 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



Zhang, et al.            Expires April 25, 2013                 [Page 1]


Internet-Draft       RSVP-TE Ext for Collecting SRLG        October 2012


   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.  RSVP-TE Requirements  . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  SRLG Collection Indication  . . . . . . . . . . . . . . . . 3
     2.2.  SRLG Collection . . . . . . . . . . . . . . . . . . . . . . 3
     2.3.  SRLG Update . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  RSVP-TE Extensions (Encoding) . . . . . . . . . . . . . . . . . 3
     3.1.  SRLG Collection Flag  . . . . . . . . . . . . . . . . . . . 4
     3.2.  SRLG sub-object . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Signaling Procedures  . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  SRLG Collection . . . . . . . . . . . . . . . . . . . . . . 5
     4.2.  SRLG Update . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Manageability Considerations  . . . . . . . . . . . . . . . . . 7
     5.1.  Policy Configuration  . . . . . . . . . . . . . . . . . . . 7
     5.2.  Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  RSVP Attribute Bit Flags  . . . . . . . . . . . . . . . . . 8
     7.2.  ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . . 8
   8.  Contributing Authors  . . . . . . . . . . . . . . . . . . . . . 8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   10. Normative References  . . . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9




















Zhang, et al.            Expires April 25, 2013                 [Page 2]


Internet-Draft       RSVP-TE Ext for Collecting SRLG        October 2012


1.  Introduction

   It is important to understand which TE links in the network might be
   at risk from the same failures.  In this sense, a set of links may
   constitute a 'shared risk link group' (SRLG) if they share a resource
   whose failure may affect all links in the set [RFC4202].

   On the other hand, as described in [RFC4206] and [RFC6107], H-LSP
   (Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying
   one or more other LSPs.  Both of the H-LSP and S-LSP can be formed as
   a TE link.  In such cases, it is important to know the SRLG
   information of the LSPs that will be used to carry further LSPs.

   This document provides an automatic mechanism to collect the SRLG for
   the TE link formed by a LSP.  Note that how to use the collected SRLG
   information is out of scope of this document


2.  RSVP-TE Requirements

2.1.  SRLG Collection Indication

   The head nodes of the LSP must be capable of indicating whether the
   SRLG information of the LSP should be collected during the signaling
   procedure of setting up an LSP.  SRLG information should not be
   collected without an explicit request for it being made by the head
   node.

2.2.  SRLG Collection

   If requested, the SRLG information should be collected during the
   setup of an LSP.  The endpoints of the LSP may use the collected SRLG
   information and use it for routing, sharing and TE link configuration
   purposes.

2.3.  SRLG Update

   When the SRLG information of an existing LSP for which SRLG
   information was collected during signaling changes, the relevant
   nodes of the LSP must be capable of updating the SRLG information of
   the LSP.  This means that that the signaling procedure must be
   capable of updating the new SRLG information.


3.  RSVP-TE Extensions (Encoding)






Zhang, et al.            Expires April 25, 2013                 [Page 3]


Internet-Draft       RSVP-TE Ext for Collecting SRLG        October 2012


3.1.  SRLG Collection Flag

   In order to indicate nodes that SRLG collection is desired, this
   document defines a new flag in the Attribute Flags TLV, which is
   carried in an LSP_REQUIRED_ATTRIBUTES Object: [Editor's note:
   LSP_ATTRIBUTES Object is also under consideration]

   o  Bit Number (to be assigned by IANA, recommended bit zero): SRLG
      Collection flag

   The SRLG Collection flag is meaningful on a Path message.  If the
   SRLG Collection flag is set to 1, it means that the SRLG information
   should be reported to the head and tail node along the setup of the
   LSP.

   The rules of the processing of the Attribute Flags TLV are not
   changed.

3.2.  SRLG sub-object

   This document defines a new RRO sub-object (ROUTE_RECORD sub-object)
   to record the SRLG information of the LSP.  Its format is modeled on
   the RRO sub-objects defined in RFC 3209 [RFC3209].

           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |     Length    |  Reserved     |    Flags      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 SRLG ID 1 (4 bytes)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                           ......                              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 SRLG ID n (4 bytes)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

   The type of the sub-object, to be assigned by IANA, which is
   recommended 34.

   Length

   The Length contains the total length of the sub-object in bytes,
   including the Type and Length fields.  The Length depends on the
   number of SRLG IDs.

   Flags



Zhang, et al.            Expires April 25, 2013                 [Page 4]


Internet-Draft       RSVP-TE Ext for Collecting SRLG        October 2012


   The Flags are used to indicate properties of the SRLG-list contained
   in the sub-object.

      0x01 = SRLG-list edited

      If set, this flag indicates that the SRLG-list contained in the
      RRO sub-object has been edited in some way by a node during
      signaling in accordance with that node's policy.

      0x02 = Partial SRLG-list

      If set, this flag indicates that the SRLG-list contained in this
      RRO sub-object is known to be incomplete.

   SRLG Id

   The 32-bit identifier of the SRLG.

   Reserved

   This field is reserved.  It SHOULD be set to zero on transmission and
   MUST be ignored on receipt.

   The rules of the processing of the LSP_REQUIRED_ATTRIBUTES Object and
   ROUTE_RECORD Object are not changed.[Editor's note: The rules of
   processing LSP_ATTRIBUTES Object (which is under consideration) are
   also not changed]


4.  Signaling Procedures

4.1.  SRLG Collection

   Typically, the head node gets the route information of an LSP by
   adding a RRO which contains the sender's IP addresses in the Path
   message.  If a head node also desires SRLG recording, it sets the
   SRLG Collection Flag in the Attribute Flags TLV which can be carried
   in an LSP_REQUIRED_ATTRIBUTES Object.

   When a node receives a Path message which carries an
   LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag is set,
   if local policy determines that the SRLG information should not be
   provided to the endpoints, it must return a PathErr message to reject
   the Path message.  Otherwise, it must add an SRLG sub-object to the
   RRO to carry the local SRLG information.  Then it forwards the Path
   message to the next node in the downstream direction.

   [Editor's note: It is under consideration that with the Path message



Zhang, et al.            Expires April 25, 2013                 [Page 5]


Internet-Draft       RSVP-TE Ext for Collecting SRLG        October 2012


   carries an LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection
   Flag is set, if local policy determines that the SRLG information
   should not be provided to the endpoints, the Path message should not
   rejected and the SRLG sub-object must not added]

   Following the steps described above, the intermediate nodes of the
   LSP can collect the SRLG information in the RRO during the forwarding
   of the Path message hop by hop.  When the Path message arrives at the
   tail node, the tail node can get the SRLG information from the RRO.

   Before the Resv message is sent to the upstream node, the tail node
   adds an SRLG sub-object to the RRO.  The collected SRLG information
   can be carried in the SRLG sub-object.  Therefore, during the
   forwarding of the Resv message in the upstream direction, the SRLG
   information is not needed to be collected hop by hop.

   Based on the above procedure, the endpoints can get the SRLG
   information automatically.  Then the endpoints can for instance
   advertise it as a TE link to the routing instance based on the
   procedure described in [RFC6107] and configure the SRLG information
   of the FA automatically.

   It is noted that a node (e.g. the edge node of a domain) may edit the
   RRO to remove the route information (e.g. node, interface identifier
   information) before forwarding it due to some reasons
   (e.g.confidentiality or reduce the size of RRO).  A node MAY edit
   SRLG information within the RRO of a Path or Resv message if dictated
   by its local policy.  If a node makes such an alteration to an
   existing RRO object, it SHOULD set the "SRLG-list edited" flag in the
   edited RRO sub-object to indicate to other nodes that this has been
   done.

   [Editor's note: Two behaviors are under consideration: using
   LSP_REQUIRED_ATTRIBUTES the collection is mandatory, while using
   LSP_ATTRIBUTES the collection is desired, but not mandatory]

4.2.  SRLG Update

   When the SRLG information of a link is changed, the LSPs using that
   link should be aware of the changes.  The procedures defined in
   Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the SRLG
   information if the SRLG change is to be communicated to other nodes
   according to the local node's policy.  If local policy is that the
   SRLG change should be suppressed or would result in no change to the
   previously signaled SRLG-list, the node need not send an update






Zhang, et al.            Expires April 25, 2013                 [Page 6]


Internet-Draft       RSVP-TE Ext for Collecting SRLG        October 2012


5.  Manageability Considerations

5.1.  Policy Configuration

   In a border node of inter-domain or inter-layer network, the
   following SRLG processing policy should be capable of being
   configured:

   o  Whether the SRLG IDs of the domain or specific layer network can
      be exposed to the nodes outside the domain or layer network, or
      whether they should be summarized or removed entirely.

   o  If SRLGs are summarized or removed, whether the "SRLG-list edited"
      flag is set in affected SRLG RRO-sub-objects.

   o  If the SRLG IDs must not be exposed to the nodes outside of the
      domain or specific layer network by policy, the border node must
      reject the Path message desiring SRLG recording and send a PathErr
      message with the defined error code 'Policy Control
      Failure'/'Inter-domain policy failure'.  [Editor's note: This last
      statement may be removed in next versions and do not impose such
      rejection.]

5.2.  Coherent SRLG IDs

   In a multi-layer multi-domain scenario, SRLG ids may be configured by
   different management entities in each layer/domain.  In such
   scenarios, maintaining a coherent set of SRLG IDs is a key
   requirement in order to be able to use the SRLG information properly.
   Thus, SRLG IDs must be unique.  Note that current procedure is
   targeted towards a scenario where the different layers and domains
   belong to the same operator, or to several coordinated administrative
   groups.

   Further scenarios, where coherence in the SRLG IDs cannot be
   guaranteed are out of the scope of the present document and are left
   for further study.


6.  Security Considerations

   TBD.


7.  IANA Considerations






Zhang, et al.            Expires April 25, 2013                 [Page 7]


Internet-Draft       RSVP-TE Ext for Collecting SRLG        October 2012


7.1.  RSVP Attribute Bit Flags

   The IANA has created a registry and manages the space of attributes
   bit flags of Attribute Flags TLV as described in section 11.3 of
   [RFC5420].  It is requested that the IANA makes assignments from the
   Attribute Bit Flags.

   This document introduces a new Attribute Bit Flag:

   o  Bit number: TBD (10)

   o  Defining RFC: this I-D

   o  Name of bit: SRLG Collection Flag

   o  The meaning of the Attribute Flags TLV on a Path is defined in
      this I-D

7.2.  ROUTE_RECORD Object

   IANA has made the following assignments in the "Class Names, Class
   Numbers, and Class Types" section of the "RSVP PARAMETERS" registry
   located at http://www.iana.org/assignments/rsvp-parameters.  We
   request that IANA make assignments from the ROUTE_RECORD RFC 3209
   [RFC3209] portions of this registry.

   This document introduces a new RRO sub-object:

             Type       Name                       Reference
             ---------  ----------------------     ---------
             TBD (34)   SRLG sub-object            This I-D


8.  Contributing Authors

      Zafar Ali
      Cisco Systems
      zali@cisco.com


9.  Acknowledgements

   The authors would like to thank Igor Bryskin, Ramon Casellas and Lou
   Berger for their useful comments to the document.







Zhang, et al.            Expires April 25, 2013                 [Page 8]


Internet-Draft       RSVP-TE Ext for Collecting SRLG        October 2012


10.  Normative References

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

   [RFC4202]  Kompella, K. and Y. Rekhter, "Routing Extensions in
              Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4202, October 2005.

   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
              Hierarchy with Generalized Multi-Protocol Label Switching
              (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC5150]  Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
              "Label Switched Path Stitching with Generalized
              Multiprotocol Label Switching Traffic Engineering (GMPLS
              TE)", RFC 5150, February 2008.

   [RFC6107]  Shiomoto, K. and A. Farrel, "Procedures for Dynamically
              Signaled Hierarchical Label Switched Paths", RFC 6107,
              February 2011.


Authors' Addresses

   Fatai Zhang (editor)
   Huawei
   F3-5-B RD Center
   Bantian, Longgang District, Shenzhen  518129
   P.R.China

   Phone:
   Email: zhangfatai@huawei.com


   Dan Li
   Huawei
   F3-5-B RD Center
   Bantian, Longgang District, Shenzhen  518129
   P.R.China

   Phone:
   Email: danli@huawei.com







Zhang, et al.            Expires April 25, 2013                 [Page 9]


Internet-Draft       RSVP-TE Ext for Collecting SRLG        October 2012


   Oscar Gonzalez de Dios (editor)
   Telefonica I+D
   Don Ramon de la Cruz
   Madrid,   28006
   Spain

   Phone: +34 913328832
   Email: ogondio@tid.es


   Cyril Margaria
   Nokia Siemens Networks
   St Martin Strasse 76
   Munich,   81541
   Germany

   Phone: +49 89 5159 16934
   Email: cyril.margaria@nsn.com


   Matt Hartley
   Cisco


   Phone:
   Email: mhartley@cisco.com

























Zhang, et al.            Expires April 25, 2013                [Page 10]


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