MPLS Working Group                                            Z. Ali
   Internet Draft                                   Cisco Systems, Inc.
   Intended status: Standard Track                        July 07, 2008
   Expires: January 06, 2008
   
   
   
          Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment
              draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt
   
   
   Status of this Memo
   
      By submitting this Internet-Draft, each author represents that
      any applicable patent or other IPR claims of which he or she is
      aware have been or will be disclosed, and any of which he or she
      becomes aware will be disclosed, in accordance with Section 6 of
      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 January 06, 2009.
   
   Copyright Notice
   
      Copyright (C) The IETF Trust (2008).
   
   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
   
   
   
                          Expires August 2007                  [Page 1]


          draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt
   
   
      address many issues that comes when a P2MP-TE LSP is signaled in
      a multi-domain networks. Specifically, one of the issues in
      multi-domain networks is how to allow computation of a loosely
      routed P2MP-TE LSP such that it is remerge free. This document
      provides a framework and required protocol extensions needed for
      establishing and controlling P2MP MPLS and GMPLS TE LSPs in
      multi-domain networks.
   
         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).
   
   Conventions used in this document
   
      In examples, "C:" and "S:" indicate lines sent by the client and
      server respectively.
   
      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.
   
   Table of Contents
   
   
      1. Introduction...............................................2
      2. Framework..................................................4
      3. RSVP-TE signaling extensions...............................4
         3.1. Multiple S2L Sub-LSPs in One Path Message.............4
         3.2. Single S2L Sub-LSPs in One Path Message...............4
         3.3. Grafting..............................................7
         3.4. Reoptimization........................................7
      4. Security Considerations....................................7
      5. IANA Considerations........................................7
      6. References.................................................7
         6.1. Normative References..................................7
         6.2. Informative References................................8
      Author's Addresses............................................8
      Intellectual Property Statement...............................8
      Disclaimer of Validity........................................8
   
   1. Introduction
   
         [RFC4875] describes how to set up point-to-multipoint (P2MP)
      Traffic Engineering Label Switched Paths (TE LSPs) for use in
   
                      Expires January 2009                     [Page 2]


          draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt
   
   
      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. E.g., the P2MP LSP must also
      handle the state "re-merge" problem, see [RFC4875]. The term "re-
      merge" refers to the case of an ingress or transit node that
      creates a branch of a P2MP LSP, a re-merge branch that intersects
      the P2MP LSP at another node farther down the tree.  This may
      occur due to such events as an error in path calculation, an
      error in manual configuration, or network topology changes during
      the establishment of the P2MP LSP. Consequently one of the
      requirements for signaling P2MP LSP is for the Ingress node to
      compute a P2MP path that is re-merge free. In some deployments,
      it may also be requires to signal P2MP LSPs that are both remerge
      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 an inter-domain environment, signaling for a given
      (Source-to-Leaf) S2L or a set of S2Ls may contain MPLS Traffic
      Engineering loosely routed explicit LSPs. A loosely routed
      explicit LSP path is a path specified as a combination of strict
      and loose hop(s) that contains at least one loose hop and zero or
      more strict hop(s). When a border node is presented with a loose
      ERO (for a given S2L or a subset of S2Ls), it may not have full
      visibility on the P2MP LSP destinations to be able to expend the
      ERO such that overall P2MP LSP is remerge free. The issue becomes
      even more acute when one path message per S2L is used.
   
      The document propose a simple extension to allow border nodes
      with just enough information about the P2MP LSP so that they can
      expand EROs for individual S2Ls such that overall P2MP LSP is
      remerge free. Specifically, this document proposes a notion of
      passing a list of addresses to a border node, for all S2Ls of a
      P2MP LSP that transits from that border node. This list of
      addresses contains addresses for which the given border node
      needs to expend the EROs to, for all S2L of the P2MP LSP that
      transit through the border router. The knowledge of other IP
      addresses w.r.t. which the route has to be re-merge free allows
                      Expires January 2009                     [Page 3]


          draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt
   
   
      for the border node to expend route for a given P2MP LSP in a re-
      merge free manner. This also allows a border node to find an
      overall better P2MP path for the LSP. However, two independent
      border routers may still expend routes for a given P2MP LSP that
      may result in a re-merge. This is because a border router is only
      given information about the s2l of the P2MP LSP that transit
      through it, and not the information about P2MP routes that are
      expend by the other border nodes. Passing around the information
      about route expended by the other border routers requires much
      more complex signaling mechanism. On the other hand, passing
      along addresses for which the given border node needs to expend
      the EROs to, for all S2L of the P2MP LSP that transit through the
      border router is petty easy and straight forward (as can be seen
      from the following section). Furthermore, it covers most of the
      remerge issue associated with signaling P2MP LSPs in a multi-
      domain environment. Furthermore, the solution also does not
      guarantee w.r.t. optimization of the overall P2MP tree. PCE
      should be used, instead, to address optimization of the overall
      P2MP tree [PCE-P2MP].
   
   2. Framework
   
      TBA
   
   
   3. RSVP-TE signaling extensions
   
      This section describes the signaling extensions required to
      address the above-mentioned functionality.
   
   3.1. Multiple S2L Sub-LSPs in One Path Message
   
      When multiple S2Ls are carried in the single Path messages 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
      border router. This enabled border node to get the information
      about all nodes this border node needs to expend EROs to. Hence,
      the border node to expend all routes in a re-merged free and a
      more cost effective manner without any protocol expansion.
   
      When multiple S2Ls are carried in the single Path messages but
      the above mentioned criteria cannot be or is not satisfied, is to
      be addressed in a later version of the document.
   
   3.2. Single S2L Sub-LSPs in One Path Message
   
      When a Path message contains only one S2L sub-LSP, the following
      extension MAY be followed to achieve ERO expansion in a remerge
                      Expires January 2009                     [Page 4]


          draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt
   
   
      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 ERO in the Path message of a P2MP LSP contains a loose hop,
      the Path message MAY (optionally) contain a "Related Addresses
      for Sibling S2L sub-LSP" object for each loose hop specified in
      the ERO.
      Class = TBA, C_Type = TBA
   
       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 with on 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 expend the EROs.
   
       0                   1                   2                   3
                      Expires January 2009                     [Page 5]


          draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt
   
   
       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 with on of the IPv6 addresses contained
      in the ERO with L flag.
   
      IPv6 address from related sibling S2L sub-LSP x
                      Expires January 2009                     [Page 6]


          draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt
   
   
   
         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 expend the EROs.
   
   3.3. Grafting
   
      Grafting for an S2L sub-LSP 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 expends the route of new S2L
      such that it's remerge free.
   
   3.4. Reoptimization
   
      TBA
   
   4. Security Considerations
   
      Security considerations and requirements from [RFC3209] 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.
   
   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
   
      [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
                and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC 3209, December 2001.
   
      [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et al,
                "Extensions to RSVP-TE for Point-to-Multipoint TE
                LSPs", RFC4875.
   
                      Expires January 2009                     [Page 7]


          draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt
   
   
      [RFC4726] A. Farrel, J.-P. Vasseur, A. Ayyangar, "A Framework for
                Inter-Domain Multiprotocol Label Switching Traffic
                Engineering", RFC 4726, November 2006.
   
   
   6.2. Informative References
   
      [PCE-P2MP] Quintin Zhao, et al, "Extensions to the Path
      Computation Element Communication Protocol (PCEP) for Point-to-
      Multipoint Traffic Engineering Label Switched Paths", draft-zhao-
      pcep-p2mp-extension-00.txt, work in progress.
   
   Author's Addresses
   
      Zafar Ali
      Cisco Systems, Inc.
      Email: zali@cisco.com
   
   
   Intellectual Property Statement
   
      The IETF takes no position regarding the validity or scope of any
      Intellectual Property Rights or other rights that might be
      claimed to pertain to the implementation or use of the technology
      described in this document or the extent to which any license
      under such rights might or might not be available; nor does it
      represent that it has made any independent effort to identify any
      such rights.  Information on the procedures with respect to
      rights in RFC documents can be found in BCP 78 and BCP 79.
   
      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the
      use of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR
      repository at http://www.ietf.org/ipr.
   
      The IETF invites any interested party to bring to its attention
      any copyrights, patents or patent applications, or other
      proprietary rights that may cover technology that may be required
      to implement this standard.  Please address the information to
      the IETF at ietf-ipr@ietf.org.
   
   Disclaimer of Validity
   
      This document and the information contained herein 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
   
                      Expires January 2009                     [Page 8]


          draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt
   
   
      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 HEREIN WILL NOT INFRINGE
      ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
      FITNESS FOR A PARTICULAR PURPOSE.
   
   Copyright Statement
   
      Copyright (C) The IETF Trust (2008).
   
      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
                      Expires January 2009                     [Page 9]