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

Versions: 00

     TEAS Working Group                                        Zafar Ali
     Internet Draft                                       George Swallow
     Intended status: Standard Track                   Clarence Filsfils
     Expires: January 5, 2016                               Matt Hartley
                                                             Ori Gerstel
                                                           Cisco Systems
                                                            Kenji Kumaki
                                                        KDDI Corporation
                                                          Ruediger Kunze
                                                     Deutsche Telekom AG
                                                            July 6, 2015
     
     
                         Include Routes - Extension to
          Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
                  draft-ali-teas-rsvp-te-include-route-00.txt
     
     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 January 5, 2016.
     
     Copyright Notice
     
     
     Copyright (c) 2015 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.
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016     [Page 1]


     Internet-Draft       draft-ali-teas-rsvp-te-include-route-00.txt
     
     
     Abstract
     
     There are scenarios that require two or more LSPs or segments of
     LSPs to follow same route in the network. This document specifies
     methods to communicate route inclusions along the loose hops during
     path setup using the Resource ReserVation Protocol-Traffic
     Engineering (RSVP-TE) protocol.
     
     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 RFC 2119
     [RFC2119].
     
     Table of Contents
     
     Copyright Notice.................................................1
     1. Introduction..................................................2
     2. RSVP-TE signaling extensions..................................4
           2.1. IPv4 Point-to-Point Path ERO subobject................4
           2.2. IPv6 Point-to-Point Path ERO subobject................5
           2.3. Processing rules for Path ERO subobjects..............7
     3. Security Considerations.......................................8
     4. IANA Considerations...........................................8
           4.1. New ERO subobject types...............................8
           4.2. New RSVP error sub-codes..............................9
     5. Acknowledgments...............................................9
     6. References...................................................10
           6.1. Normative References.................................10
           6.2. Informative References...............................10
     
     1. Introduction
     
        There are scenarios that require two or more Label Switched
        Paths (LSPs) to follow same route in the network. E.g., many
        deployments require member LSPs of a bundle/ aggregated link (or
        Forwarding Adjacency (FA))) follow the same route. Possible
        reasons for two or more LSPs to follow the same end-to-end or
        partial route include, but are not limited to:
     
        .  Fate sharing: an application may require that two or more
          LSPs fail together. In the example of bundle link this would
     
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016       [Page 2]


     Internet-Draft       draft-ali-teas-rsvp-te-include-route-00.txt
     
     
          mean that if one component goes down, the entire bundle goes
          down.
     
        .  Homogeneous Attributes: it is often required that two or more
          LSPs have the same TE metrics like latency, latency variation,
          etc. In the example of a bundle/ aggregated link this would
          meet the requirement that all component links (FAs) of a
          bundle should have same latency and latency variation. As
          noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain
          networks, such as financial information networks, network
          performance (e.g. latency and latency variation) is becoming
          critical and hence having bundles with component links (FAs)
          with homogeneous latency and latency variation is important.
     
        The RSVP-TE specification [RFC3209] and GMPLS extensions to
        RSVP-TE [RFC3473] allow abstract nodes and resources to be
        explicitly included in a path setup, e.g., using IPv4 prefix ERO
        subobject [RFC3209], IPv6 prefix ERO subobject [RFC3209] and
        Unnumbered Interface ID ERO subobject [RFC3477], etc. When a
        source node has full topological knowledge and is permitted to
        signal an Explicit Route Object, these methods can be used to
        satisfy the inclusion requirements mentioned above. However,
        there are scenarios when path computations are performed by
        remote nodes, thus there is a need for relevant inclusion
        requirements to be communicated to those nodes. These include
        (but are not limited to):
     
       .  LSPs with loose hops in the Explicit Route Object (ERO), e.g.
          inter-domain LSPs;
     
       .  Generalized Multi-Protocol Label Switching (GMPLS) User-
          Network Interface (UNI) where path computation may be
          performed by the (server layer) core node [RFC4208].
     
       These use-cases require the relevant path-inclusion information
       to be communicated to the route expanding nodes. This document
       defines the necessary extensions to RSVP-TE protocol.
     
       This document assumes that node expanding the route is normally a
       hop of the included LSP. Therefore, the node calculating or
       expanding the route of the signaled LSP has the knowledge of the
       inclusion route.
     
       However, there is a race condition in which included LSP is yet
       to be signaled. This draft addresses this race condition, as
       detailed in Section 2.2.
     
     
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016       [Page 3]


     Internet-Draft       draft-ali-teas-rsvp-te-include-route-00.txt
     
     
     2. RSVP-TE signaling extensions
     
        New IPv4 and IPv6 Point-to-Point (P2P) Path ERO subobject types
        are defined in this document. These ERO subobjects are used to
        communicate path inclusion requirements to the ERO expanding
        node(s). For this purpose, the subobjects carry RSVP-TE
        Forwarding Equivalence Class (FEC) of the reference LSP who's
        Path is be used to expand the loose hop of the LSP being
        signaled.
     
     2.1. IPv4 Point-to-Point Path ERO subobject
     
        The IPv4 Point-to-Point Path ERO subobject is defined as
        follows:
     
         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |L|    Type     |     Length    |M|                Reserved     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 IPv4 tunnel end point address                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Reserved (MUST be zero)     |     Tunnel ID                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Extended Tunnel ID                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   IPv4 tunnel sender address                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Reserved (MUST be zero)     |            LSP ID             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     
          L
               The L bit is an attribute of the subobject.  The L bit is
               set if the subobject represents a loose hop in the ERO.
               If the bit is not set, the subobject represents a strict
               hop in the explicit route.
     
               This document only defines the use of the subobject in
               loose hopes in the ERO, i.e., L bit MUST of set to 1.
     
          Type
     
               IPv4 Point-to-Point Path ERO subobject
               (to be assigned by IANA; suggested value: 38).
     
     
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016       [Page 4]


     Internet-Draft       draft-ali-teas-rsvp-te-include-route-00.txt
     
     
          Length
     
              The length contains the total length of the subobject in
              bytes, including the type and length fields. The length is
              always 24.
     
          M bit: When "mandatory inclusion" bit is set, the route of the
          LSP being signaled MUST follow the path specified by the Path
          ERO subobject. When mandatory inclusion is not set, the route
          of the LSP being signaled SHOULD follow the path specified by
          the Path ERO subobject.
     
     
          The remaining fields are used to specify RSVP-TE FEC of the
          reference LSP who's Path is be used to expand the route of the
          LSP being signaled. Specifically,
     
          Tunnel ID
     
               Tunnel ID of the reference LSP who's Path is be used to
               expand the route of the LSP being signaled.
     
          Extended Tunnel ID
     
               Extended Tunnel ID of the reference LSP who's Path is be
               used to expand the route of the LSP being signaled.
     
          IPv4 tunnel sender address
     
               IPv4 tunnel sender address of the reference LSP who's
               path is be used to expand the route of the LSP being
               signaled.
     
          LSP ID
     
               LSP ID of the reference LSP who's Path is be used to
               expand the route of the LSP being signaled.
     
     
     
     2.2. IPv6 Point-to-Point Path ERO subobject
     
        The IPv6 Point-to-Point Path ERO subobject is defined as
        follows:
     
     
     
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016       [Page 5]


     Internet-Draft       draft-ali-teas-rsvp-te-include-route-00.txt
     
     
          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |L|    Type     |     Length    |M|                Reserved     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 IPv6 tunnel end point address                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             IPv6 tunnel end point address (cont.)             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             IPv6 tunnel end point address (cont.)             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             IPv6 tunnel end point address (cont.)             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Must Be Zero         |     Tunnel ID                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Extended Tunnel ID                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   Extended Tunnel ID (cont.)                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   Extended Tunnel ID (cont.)                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   Extended Tunnel ID (cont.)                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   IPv4 tunnel sender address                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               IPv4 tunnel sender address (cont.)              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               IPv4 tunnel sender address (cont.)              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |               IPv4 tunnel sender address (cont.)              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Reserved (MUST be zero)     |            LSP ID             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
          L
               The L bit is an attribute of the subobject.  The L bit is
               set if the subobject represents a loose hop in the ERO.
               If the bit is not set, the subobject represents a strict
               hop in the explicit route.
     
               This document only defines the use of the subobject in
               loose hopes in the ERO, i.e., L bit MUST of set to 1.
     
          Type
     
               IPv6 Point-to-Point Path ERO subobject
     
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016       [Page 6]


     Internet-Draft       draft-ali-teas-rsvp-te-include-route-00.txt
     
     
               (to be assigned by IANA; suggested value: 39).
     
     
          Length
     
              The length contains the total length of the subobject in
              bytes, including the type and length fields. The length is
              always 48.
     
          M bit: The M bit usage is as defined for the M bit of IPv4
          Point-to-Point Path ERO subobject.
     
          The remaining fields are used to specific RSVP-TE FEC of the
          reference LSP who's Path is be used to expand the route of the
          LSP being signaled, as detailed in Section 2.1.
     
     2.3. Processing rules for Path ERO subobjects
     
        The basic processing rules of an ERO are not altered.  Please
        refer to [RFC3209] for details.
     
        If an LSR strips all local subobjects from an ERO carried in a
        Path message (according to the procedures in [RFC3209]) and
        finds that the next subobject is an IPv4 P2P Path ERO subobject
        or IPv6 P2P LSP subject, it MUST attempt to resolve the Path ERO
        subobject as described in the following.
     
        If the L bit of the Path ERO subobject is not set, i.e., the
        subobject represents a strict hop in the explicit route, the
        processing node MUST respond with a PathErr message with the
        error code "Routing Problem" (24) and the error value "Bad
        initial subobject" (4).
     
        If the M bit is set, the processing node follows the following
        procedure:
     
        -  If the path taken by the LSP referenced in the Path ERO
          subobject is known to the processing node and the path
          contains the loose abstract node in the ERO hop, the
          processing node MUST ensure that loose hop expansion to the
          next abstract node follows the referenced path.
     
        -  If the path taken by the LSP referenced in the Path ERO
          subobject does not contain the loose abstract node in the ERO
          hop, the processing node MUST sent a PathErr message with the
          error code "Routing Problem" (24) and the new error value
     
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016       [Page 7]


     Internet-Draft       draft-ali-teas-rsvp-te-include-route-00.txt
     
     
          "unknown or inconsistent LSP suboject" (value to be assigned
          by IANA) for the signaled LSP.
     
        -  If the path referenced in the LSP subobject is unknown to the
          processing node, the processing node SHOULD ignore the Path
          ERO subobject and SHOULD proceed with the signaling request.
          After sending the Resv for the signaled LSP, the processing
          node SHOULD return a PathErr with the error code "Notify
          Error" (25) and error sub-code "TBD" (value to be assigned by
          IANA, suggested value: TBD) for the signaled LSP.
     
        If the M bit is not set, the processing node follows the
        following procedure:
     
        -  If the path taken by the LSP referenced in the Path ERO
          subobject is known to the processing node and the path
          contains the loose abstract node in the ERO hop, the
          processing node SHOULD ensure that loose hop expansion to the
          next abstract node follows the referenced path.
     
        -  If the path taken by the LSP referenced in the Path ERO
          subobject is unknown to the processing node and/ or the
          referenced path does not contain the loose abstract node in
          the ERO hop, the processing node SHOULD ignore the route
          inclusion specified in the Path ERO subobject and SHOULD
          compute a suitable path to the loose abstract node in the ERO
          hop and proceed with the signaling request. After sending the
          Resv for the signaled LSP, the processing node SHOULD return a
          PathErr with the error code "Notify Error" (25) and error sub-
          code " unknown or inconsistent LSP suboject" (value to be
          assigned by IANA) for the signaled LSP.
     
     3. Security Considerations
     
        This document does not introduce any additional security issues
        above those identified in [RFC5920], [RFC2205], [RFC3209], and
        [RFC3473] and [RFC4874].
     
     4. IANA Considerations
     
     4.1. New ERO subobject types
     
        This document adds the following new subobject of the existing
        entry for ERO (20, EXPLICIT_ROUTE):
     
        Value                      Description
     
     
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016       [Page 8]


     Internet-Draft       draft-ali-teas-rsvp-te-include-route-00.txt
     
     
        -----                      ------------
     
        TBA                        IPv4 Point-to-Point Path ERO
        subobject
     
        TBA                        IPv6 Point-to-Point Path ERO
        subobject
     
        These subobject may be present in the Explicit Route Object, but
        not in the Route Record Object.
     
     
     4.2. New RSVP error sub-codes
     
        IANA registry: RSVP PARAMETERS
        Subsection: Error Codes and Globally-Defined Error Value Sub-
        Codes
     
        For Error Code "Routing Problem" (24) (see [RFC3209]) the
        following sub-codes are defined.
     
        Sub-code                               Value
        --------                               -----
     
        Unknown or inconsistent LSP suboject   To be assigned by IANA.
     
        For Error Code "Notify Error" (25) (see [RFC3209]) the following
        sub-codes are defined.
     
     
        Sub-code                               Value
        --------                               -----
     
        Unknown or inconsistent LSP suboject   To be assigned by IANA.
     
     
     5. Acknowledgments
     
        Authors would like to thank Gabriele Maria Galimberti, Luyuan
        Fang and Walid Wakim for their review comments.
     
     
     
     
     
     
     
     
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016       [Page 9]


     Internet-Draft       draft-ali-teas-rsvp-te-include-route-00.txt
     
     
     6. References
     
     6.1. Normative References
     
        [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.
     
        [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.
     
        [RFC3473] Berger, L., "Generalized Multi-Protocol Label
                  Switching (GMPLS) Signaling Resource ReserVation
                  Protocol-Traffic Engineering (RSVP-TE) Extensions",
                  RFC 3473, January 2003.
     
     
     6.2. Informative References
     
        [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
                  "Generalized Multiprotocol Label Switching (GMPLS)
                  User-Network Interface (UNI): Resource ReserVation
                  Protocol-Traffic Engineering (RSVP-TE) Support for the
                  Overlay Model", RFC 4208, October 2005.
     
        [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K.,
                  Brungard, D., and JL. Le Roux, "Generalized MPLS
                  (GMPLS) Protocol Extensions for Multi-Layer and Multi-
                  Region Networks (MLN/MRN)", RFC 6001, October 2010.
     
        [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                  Links in Resource ReSerVation Protocol - Traffic
                  Engineering (RSVP-TE)", RFC 3477, January 2003.
     
        [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation
                  Protocol (RSVP) -- Version 1 Message Processing
                  Rules", RFC 2209, September 1997.
     
        [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
                  Networks", RFC 5920, July 2010.
     
     Authors' Addresses
     
     
     
     
     
     
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016       [Page 10]


     Internet-Draft       draft-ali-teas-rsvp-te-include-route-00.txt
     
     
        Zafar Ali
        Cisco Systems, Inc.
        Email: zali@cisco.com
     
        George Swallow
        Cisco Systems, Inc.
        swallow@cisco.com
     
        Clarence Filsfils
        Cisco Systems, Inc.
        cfilsfil@cisco.com
     
        Matt Hartley
        Cisco Systems
        Email: mhartley@cisco.com
     
        Ori Gerstel
        Cisco Systems
        ogerstel@cisco.com
     
        Kenji Kumaki
        KDDI Corporation
        Email: ke-kumaki@kddi.com
     
        Rudiger Kunze
        Deutsche Telekom AG
        Ruediger.Kunze@telekom.de
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Ali, Swallow, Filsfils, et al   Expires Januray 2016       [Page 11]
     

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