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

Versions: (draft-ietf-mpls-interas-lspping) 00 01 02 03 04 05 06 07 08 09 draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp

MPLS Working Group                                           Z. Ali, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                                N. Neate
Expires: September 8, 2009                           Data Connection Ltd
                                                           March 9, 2009

       Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment
          draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-02.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.  This document may contain
   material from IETF Documents or IETF Contributions published or
   made publicly available before November 10, 2008.  The person(s)
   controlling the copyright in some of this material may not have
   granted the IETF Trust the right to allow modifications of such
   material outside the IETF Standards Process.  Without obtaining
   an adequate license from the person(s) controlling the copyright
   in such materials, this document may not be modified outside the
   IETF Standards Process, and derivative works of it may not be
   created outside the IETF Standards Process, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   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 08, 2009.

Abstract

   Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE
   LSPs) may be established using signaling techniques described in
   [RFC4875].  However, [RFC4875] does not address issues that arise
   when a P2MP-TE LSP is signaled in multi-domain networks.
   Specifically, it does not provide a mechanism to avoid re-merges in
   inter-domain P2MP TE LSPs.  This document provides a framework and
   protocol extensions for establishing and controlling P2MP MPLS and
   GMPLS TE LSPs in multi-domain networks.

Ali & Neate             Expires September 5, 2009               [Page 1]


Internet-Draft       RSVP-TE P2MP Inter-domain LSPs           March 2009


   This document borrows inter-domain TE terminology from [RFC4726],
   e.g., for the purposes of this document, a domain is considered to be
   any collection of network elements within a common sphere of address
   management or path computational responsibility.  Examples of such
   domains include Interior Gateway Protocol (IGP) areas and Autonomous
   Systems (ASes).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions used in this document  . . . . . . . . . . . .  4
   2.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  RSVP-TE signaling extensions . . . . . . . . . . . . . . . . .  4
     3.1.  SIBLING_S2L object . . . . . . . . . . . . . . . . . . . .  4
       3.1.1.  Format . . . . . . . . . . . . . . . . . . . . . . . .  4
       3.1.2.  Processing . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Grafting . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Crankback and Path Error . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10


























Ali & Neate             Expires September 5, 2009               [Page 2]


Internet-Draft       RSVP-TE P2MP Inter-domain LSPs           March 2009


1.  Introduction

   [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
   Engineering Label Switched Paths (TE LSPs) for use in MultiProtocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

   As with all other RSVP controlled LSPs, P2MP LSP state is managed
   using RSVP messages.  While the use of RSVP messages is mostly
   similar to their P2P counterpart, P2MP LSP state differs from P2P LSP
   in a number of ways.  In particular, the P2MP LSP must also handle
   the "re-merge" problem described in [RFC4875] section 18.

   The term "re-merge" refers to the situation when two S2L sub-LSPs
   branch at some point in the P2MP tree, and then intersect again at a
   another node further down the tree.  This may occur due to
   discrepencies in the routing algorithms used by different nodes,
   errors in path calculation or manual configuration, or network
   topology changes during the establishment of the P2MP LSP.  Such re-
   merges are inefficient due to the unnecessary duplication of data.
   Consequently one of the requirements for signaling P2MP LSPs is
   choose a P2MP path that is re-merge free.  In some deployments, it
   may also be required to signal P2MP LSPs that are both re-merge and
   crossover free [RFC4875].

   This requirement becomes more acute to address when P2MP LSP spans
   multiple domains.  For the purposes of this document, a domain is
   considered to be any collection of network elements within a common
   sphere of address management or path computational responsibility.
   Examples of such domains include Interior Gateway Protocol (IGP)
   areas and Autonomous Systems (ASes).  This is because in an inter-
   domain environment, the ingress node may not have topological
   visibility into other domains to be able to compute and signal a re-
   merge free P2MP LSP.  In that case, the border node for a new domain
   will be given one or more loose next hops for the P2MP LSP.  When
   processing a path message, it may not have knowledge of all of the
   destinations of the P2MP LSP, either because S2L sub-LSPs are split
   between multiple Path messages, or because not all S2L sub-LSPs pass
   through this border node.  In that case, existing protocol mechanisms
   do not provide sufficient information for it to be able to expand the
   loose hop(s) in such a way that the overall P2MP path is guaranteed
   to be optimal and re-merge free.

   This document proposes a simple extension to provide border nodes
   with sufficient information about the P2MP LSP to be able to expand
   EROs for individual S2L sub-LSPs such that overall P2MP LSP is re-
   merge free.  Specifically, this document defines a mechanism for
   including a list of addresses in a Path message sent to a border
   node, each of which is the next ERO hop address for an S2L sub-LSP



Ali & Neate             Expires September 5, 2009               [Page 3]


Internet-Draft       RSVP-TE P2MP Inter-domain LSPs           March 2009


   that is not itself included in the Path message.  The border node can
   then compute a P2MP route for the complete P2MP LSP even when
   signaling just a subset of the S2L sub-LSPs, thus guaranteeing that
   the final P2MP path is optimal and re-merge free within that domain.

   The need for finding an end-to-end path that is re-merge free also
   increases chances of crankbacks during setting up P2MP LSPs as
   compared to their P2P counterparts.  Nonetheless, crankback
   mechanisms for P2MP LSPs are not addressed by [RFC4875].  This
   document also describes how crankback signaling extensions for MPLS
   and GMPLS RSVP-TE defined in [RFC4920] apply to setting up P2MP TE
   LSPs.

   The solution also does not guarantee optimization of the overall P2MP
   tree across all domains.  PCE can be used, instead, to address
   optimization of the overall P2MP tree [REFERENCE NOT FOUND].

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


2.  Framework

   TBA


3.  RSVP-TE signaling extensions

   This section describes the signaling extensions required to address
   the above-mentioned functionality.

3.1.  SIBLING_S2L object

   The SIBLING_S2L object is signaled in RSVP-TE Path messages and
   describes related addresses for Sibling S2L sub-LSPs that should be
   considered when doing loose ERO hop expansion.

3.1.1.  Format

   The IPv4 SIBLING_S2L object (Class = TBA, C-Type = TBA) has the
   format:







Ali & Neate             Expires September 5, 2009               [Page 4]


Internet-Draft       RSVP-TE P2MP Inter-domain LSPs           March 2009


    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        IPv4 address of the border node                        |
   |        IPv4 address from related sibling S2L sub-LSP 1        |
   |        IPv4 address from related sibling S2L sub-LSP 2        |
   |        IPv4 address from related sibling S2L sub-LSP 1        |
   //                                                             //
   |        IPv4 address from related sibling S2L sub-LSP last     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      0x01 IPv4 address

   Length

      The Length contains the total length of the object in bytes,
      including the Type and Length fields.  The Length is variable
      depending on the addresses in the list.

   IPv4 address of the border node

      IPv4 address of the target border node, where ERO extension for
      this and related S2L sub-LSPs of the P2MP LSP is desired.  This
      address MUST match one of the IPv4 addresses contained in the ERO
      with L flag.

   IPv4 address from related sibling S2L sub-LSP x

      IPv4 address of a node on another sibling S2L sub-LSP x, which is
      signaled in a separate Path message but which also require ERO
      extension at the border node contained in IPv4 address of the
      border node field.  Together this list contains all addresses on a
      given P2MP LSP to which the border node needs to expand the EROs.

   The IPv6 SIBLING_S2L object (Class = TBA, C-Type = TBA) has the
   format:











Ali & Neate             Expires September 5, 2009               [Page 5]


Internet-Draft       RSVP-TE P2MP Inter-domain LSPs           March 2009


    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        IPv6 address of the border node                        |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        IPv6 address from related sibling S2L sub-LSP 1        |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        IPv6 address from related sibling S2L sub-LSP 2        |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        IPv6 address from related sibling S2L sub-LSP 1        |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                                                             //
   |        IPv6 address from related sibling S2L sub-LSP last     |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      0x02 IPv6 address

   Length

      The Length contains the total length of the object in bytes,
      including the Type and Length fields.  The Length is variable
      depending on the addresses in the list.

   IPv6 address of the border node

      IPv6 address of the target border node, where ERO extension for
      this and related S2L sub-LSPs of the P2MP LSP is desired.  This
      address MUST match one of the IPv6 addresses contained in the ERO
      with L flag.



Ali & Neate             Expires September 5, 2009               [Page 6]


Internet-Draft       RSVP-TE P2MP Inter-domain LSPs           March 2009


   IPv6 address from related sibling S2L sub-LSP x

      IPv6 address of a node on another sibling S2L sub-LSP x, which is
      signaled in a separate Path message but which also require ERO
      extension at the border node contained in IPv6 address of the
      border node field.  Together this list contains all addresses on a
      given P2MP LSP to which the border node needs to expand the EROs.

3.1.2.  Processing

3.1.2.1.  Multiple S2L Sub-LSPs in Each Path Message

   When multiple S2L sub-LSPs are carried in each Path message it is
   RECOMMENDED that P2MP LSP is partitioned in such a way that the Path
   message to a border node, where ERO expansion is desired, contains
   all S2Ls of the P2MP LSP that transit through that domain.  This
   provides the border node with information about all the loose ERO
   hops it needs to expand.

   It may be that signaling all those S2L sub-LSPs in the same Path
   message is not possible because doing so would exceed the size limit
   for the message, or because not all S2L sub-LSPs enter the domain
   through the same border node.  Procedures to handle those cases will
   be addressed in a later version of this document.

3.1.2.2.  Single S2L Sub-LSP in Each Path Message

   When each Path message contains only one S2L sub-LSP, the following
   procedures MAY be followed to achieve ERO expansion in a re-merge
   free and a more cost effective manner.  As specified in [RFC3209],
   loose hops are listed in the ERO object of the RSVP Path message with
   the L flag of the IPv4 or the IPv6 prefix sub-object set.  When the
   ERO in the Path message of a P2MP LSP contains a loose hop, the Path
   message MAY (optionally) contain a SIBLING_S2L object for each loose
   hop specified in the ERO.

3.2.  Grafting

   Grafting for an S2L sub-LSP is achieved by the ingress node signaling
   it with the same P2MP ID and LSP ID, via existing or new border nodes
   with loose hop expansion.  If an existing border node is used along
   the path, the border node locally finds how ERO expansions for other
   siblings of the P2MP LSP transiting through this border node is done
   and expands the route of new S2L such that it's re-merge free.







Ali & Neate             Expires September 5, 2009               [Page 7]


Internet-Draft       RSVP-TE P2MP Inter-domain LSPs           March 2009


3.3.  Crankback and Path Error

   Crankback procedures for rerouting around failures for P2P RSVP-TE
   LSPs are defined in [RFC4920].  These techniques can also be applied
   to P2MP LSPs, as decribed in this section.

   It is RECOMMENDED that boundary re-routing or segment-based re-
   routing is requested for P2MP LSPs traversing multiple domains.  This
   is because border nodes that are expanding loose hops are typically
   best placed to correct any re-merge errors that occur within their
   domain, not the ingress node.

   If a node on the path of the P2MP LSP is unable to find a route that
   can supply the required resources or is not re-merge free, it SHOULD
   generate a Path Error message for the subset of the S2L sub-LSPs
   which it is not able to route.  For this purpose the node SHOULD try
   to find a minimum subset of S2L sub-LSPs for which the Path Error
   needs to be generated.  This rule applies equally to the case where
   multiple S2L Sub-LSPs are signaled using one Path message, as to the
   case where a single S2L Sub-LSP is signaled in each Path message.
   GMPLS Notify messages do not include S2L_SUB_LSP objects and cannot
   be used to send errors for a subset of the S2L sub-LSPs in a Path
   message.  For that reason, the node SHOULD use a Path Error message
   rather than a Notify message to communicate the error.  In the case
   of a re-merge error, the node SHOULD use the Error Code "Routing
   Problem" and the Error Value "ERO resulted in re-merge" as specified
   in [RFC4875].

   A border node receiving a Path Error should attempt to re-route
   according to the crankback procedures defined in [RFC4920].  In the
   case of a re-merge error for which some of the re-merging S2L sub-
   LSPs do not pass through the border node, it should propagate the
   Path Error usptream.  The first node through which all S2L sub-LSPs
   concerned transit which receives the Path Error and is allowed to
   perform crankback procedures should re-route the S2L sub-LSPs
   concerned to all use the same border node.


4.  Security Considerations

   Security considerations and requirements from [RFC4875] and [RFC4875]
   apply equally to this document.  Furthermore, there are some
   additional security considerations that may be induced by the use of
   "Related Addresses for Sibling S2L sub-LSP" object defined in this
   document.  These security considerations will be added in a later
   version of the draft.





Ali & Neate             Expires September 5, 2009               [Page 8]


Internet-Draft       RSVP-TE P2MP Inter-domain LSPs           March 2009


5.  IANA Considerations

   Code points for "Related Addresses for Sibling S2L sub-LSP" object
   defined in this document will be required.  Much of the details here
   are TBA.


6.  References

6.1.  Normative References

   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
              "Extensions to Resource Reservation Protocol - Traffic
              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
              Switched Paths (LSPs)", RFC 4875, May 2007.

   [RFC4920]  Farrel, A., Satyanarayana, A., Iwata, A., Fujita, N., and
              G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS
              RSVP-TE", RFC 4920, July 2007.

6.2.  Informative References

   [RFC4726]  Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
              Inter-Domain Multiprotocol Label Switching Traffic
              Engineering", RFC 4726, November 2006.

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


Authors' Addresses

   Zafar Ali (editor)
   Cisco Systems, Inc.
   Email: zali@cisco.com


   Nic Neate
   Data Connection Ltd
   100 Church Street
   Enfield  EN2 6BQ
   United Kingdom
   Email: nhn@dataconnection.com





Ali & Neate             Expires September 5, 2009               [Page 9]


Internet-Draft       RSVP-TE P2MP Inter-domain LSPs           March 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.


Legal

   This documents and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
   OR FITNESS FOR A PARTICULAR PURPOSE.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s)
   controlling the copyright in such materials, this document may not
   be modified outside the IETF Standards Process, and derivative
   works of it may not be created outside the IETF Standards Process,
   except to format it for publication as an RFC or to translate it
   into languages other than English.











Ali & Neate             Expires September 5, 2009              [Page 10]


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