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

Versions: 00 01

Network Working Group                                          Y. Brehon
Internet-Draft                                              M. Vigoureux
Intended status: Standards Track                            L. Ciavaglia
Expires: May 22, 2008                                     Alcatel-Lucent
                                                              M. Chaitou
                                                          France Telecom
                                                                  Z. Ali
                                                     Cisco Systems, Inc.
                                                       November 19, 2007


    IGP Routing Protocol Extensions for Discovery of Upstream Label
                       Assignment Node Capability
          draft-brevigcia-ccamp-mpls-upstream-node-cap-01.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 May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).








Brehon, et al.            Expires May 22, 2008                  [Page 1]


Internet-Draft              Upstream-Node-Cap              November 2007


Abstract

   This document proposes an extension to [TE-NODE-CAP] in order to
   support additional TE node capabilities in the context of Point-to-
   MultiPoint (P2MP) LSP routing and fast reroute protection.  As for
   point-to-point LSP, nesting P2MP LSPs, i.e., MPLS P2MP hierarchy, is
   a desirable traffic-engineering feature.  However, nesting P2MP LSPs
   requires a mechanism to coordinate the label allocation of the inner
   P2MP LSP between the egress nodes of the P2MP Tunnel as described in
   [MPLS-UPSTREAM].  To solve this issue, a new label allocation scheme
   called Upstream Label Assignment (ULA) is defined.  Network elements
   responsible for the route computation of P2MP LSP should be aware of
   the nodes that support this functionality.  For that purpose, we
   define a new bit flag to the TE Node Capability Descriptor as defined
   in [TE-NODE-CAP].  The bit flag (U) enables a node to advertise its
   capability to accept Upstream Label Assignment.



































Brehon, et al.            Expires May 22, 2008                  [Page 2]


Internet-Draft              Upstream-Node-Cap              November 2007


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Advantages of the solution . . . . . . . . . . . . . . . . . .  7
   4.  New value to the TE Node Capability Descriptor . . . . . . . .  9
   5.  Elements of procedure  . . . . . . . . . . . . . . . . . . . . 10
   6.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Capability Registry  . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16





































Brehon, et al.            Expires May 22, 2008                  [Page 3]


Internet-Draft              Upstream-Node-Cap              November 2007


1.  Terminology

   This document uses terminologies defined in [RFC3031], [RFC3209] and
   [RFC4461].

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











































Brehon, et al.            Expires May 22, 2008                  [Page 4]


Internet-Draft              Upstream-Node-Cap              November 2007


2.  Introduction

   This document proposes an extension to [TE-NODE-CAP] in order to
   support additional TE node capabilities in the context of Point-to-
   MultiPoint (P2MP) LSP routing and Fast ReRoute protection.  As for
   point-to-point LSP, nesting P2MP LSPs, i.e., MPLS P2MP hierarchy, is
   a desirable traffic-engineering feature.  P2MP Fast ReRoute (FRR)
   [P2MP-FRR] is a typical application of P2MP LSPs nesting that is
   likely to be deployed in MPLS-TE networks transporting multicast
   traffic.

   However, nesting P2MP LSPs requires a mechanism to coordinate the
   label allocation of the inner P2MP LSP between the egress nodes of
   the P2MP Tunnel as described in [MPLS-UPSTREAM].  To solve this
   issue, a new label allocation scheme called Upstream Label Assignment
   (ULA) is defined where the ingress node of the P2MP Tunnel allocates
   a single label to the egress nodes of the P2MP Tunnel for the nested
   P2MP LSP.  Use of this technique raises an additional issue: as the
   upstream neighbor now assigns the label, two different upstream nodes
   may allocate the same label value to the same receiver(s) for two
   different P2MP LSPs nested in different P2MP Tunnels.  The egress
   nodes cannot anymore distinguish the LSPs based on the incoming label
   value.  To overcome this issue, [MPLS-UPSTREAM] defines a Context-
   specific Label Space (CLS).  The egress node must now disambiguate
   the label of the inner LSP by defining a per-upstream-neighbour label
   space.  As defined in [MPLS-UPSTREAM], downstream LSRs maintain
   separate label space for each unique root (a P2MP Tunnel head-end)
   and MUST be able to determine the root of the P2MP Tunnels.  The root
   is identified by the head-end IP address of the Tunnel.  If the same
   upstream node uses different head-end IP addresses for different
   tunnels then the downstream nodes MUST maintain a different Upstream
   Neighbor Label Space for each such head-end IP address.

   [RSVP-UPSTREAM] defines extensions to [RFC4875] to support the
   advertisement of the ULA capability between adjacent nodes - i.e.,
   between nodes which have a signaling adjacency.  Unfortunately, when
   nesting P2MP LSPs in P2MP Tunnels, the ingress nodes and the egress
   nodes usually do not have such a signaling adjacency.  Nevertheless,
   the knowledge of this capability is crucial when calculating the
   routes of nested P2MP LSPs over P2MP tunnels (either by the ingress
   node or by a Path Computation Element, PCE).  If the ingress of the
   (nested) P2MP LSP or the PCE does not have a control adjacency with
   the egress nodes of the P2MP Tunnel, LSP setup will be tried and will
   fail if at least one egress node does not support the ULA capability.
   This is a trial-and-error approach, which can reveal inefficient and
   time and resource consuming.

   The idea is thus to extend the MPLS/GMPLS routing protocols (OSPF-TE



Brehon, et al.            Expires May 22, 2008                  [Page 5]


Internet-Draft              Upstream-Node-Cap              November 2007


   and IS-IS-TE) to allow LSRs to inform all nodes within a network
   domain of a node's capability to receive upstream-assigned labels and
   process them accordingly.  Using the routing protocol guarantees this
   information will be distributed to all nodes, which should perform
   route calculations, independently of the signaling protocol used for
   establishing the LSPs (e.g.  RSVP-TE).

   For that purpose, this document defines a new bit flag to the TE Node
   Capability Descriptor as defined in [TE-NODE-CAP].  The bit flag (U)
   enables a node to advertise its capability to accept Upstream Label
   Assignment.








































Brehon, et al.            Expires May 22, 2008                  [Page 6]


Internet-Draft              Upstream-Node-Cap              November 2007


3.  Advantages of the solution

   The advertisement of the ULA capability across the network brings
   additional Traffic Engineering possibilities to better manage P2MP TE
   LSPs.

   A first advantage of the proposed solution concerns P2MP TE path
   computation.  When transporting multicast traffic over their MPLS
   networks, service providers and operators will often establish P2MP
   TE Tunnels and nest the client P2MP LSPs into them in order to keep
   control of the planning and resource allocation in their networks.

   As described briefly above, remote nodes at the endpoints of tunnels
   do not usually establish signaling adjacency because this would
   result in a fully connected graph where each node would have a
   control adjacency with all other nodes in the network.  Similarly, if
   the network operator uses a PCE to calculate P2MP TE paths, the
   knowledge of the ULA capability cannot be advertised by the signaling
   protocols.  Therefore, in order to avoid these blocking situations
   and to allow remote nodes to efficiently calculate TE P2MP paths with
   all the relevant information, disseminating the node capability to
   accept upstream-assigned labels through IGP routing protocols appears
   as a desirable feature and seems a scalable and efficient approach.

   Moreover, if an operator wishes to setup P2MP tunnels to transport
   P2MP LSPs, the egress nodes of the P2MP tunnel will have to support
   ULA.  Therefore, it is pointless to setup a P2MP tunnel to only
   afterwards fail in all nested P2MP LSP establishments; it is much
   more efficient to have the relevant information for the P2MP tunnel
   setup right from the start.

   A second advantage of the proposed solution concerns P2MP fast
   reroute protection.  As described in [P2MP-FRR], in the P2MP Facility
   Backup method, a P2MP Bypass Tunnel can be used to protect a set of
   P2MP TE LSPs.  During failure, the same backup label MUST be used for
   all S2L sub-LSPs of a given backup P2MP LSP, tunneled within the same
   P2MP Bypass Tunnel to avoid data replication and traffic mis-routing
   in the Merge Points (MP).  The Point of Local Repair (PLR) assigns
   the same label to all the Merge Points (MP) using the Upstream Label
   Assignment procedure.

   The backup P2MP LSPs and the P2MP Bypass tunnel have to be
   established prior to the failure and to work properly, the mechanism
   needs to know the capability of the remote nodes to accept upstream-
   assigned labels.  If some egress nodes do not support ULA, then the
   PLR will establish dedicated P2P Tunnels towards them.

   In P2MP FRR protection, the knowledge of the ULA capability is vital



Brehon, et al.            Expires May 22, 2008                  [Page 7]


Internet-Draft              Upstream-Node-Cap              November 2007


   and particularly important in order to limit the number of trials
   before the appropriate backup LSP(s) are found and established.

   Globally, the proposed solution to transport the ULA capability bit
   in IGP routing protocols enables:

   o  a scalable dissemination of the P2MP node capabilities,

   o  a workable fast reroute protection mechanism,

   o  a higher reliability/robustness of the signaling phase.








































Brehon, et al.            Expires May 22, 2008                  [Page 8]


Internet-Draft              Upstream-Node-Cap              November 2007


4.  New value to the TE Node Capability Descriptor

   The TE Node Capability Descriptor contains a variable length set of
   bit flags, where each bit corresponds to a given TE node capability.

   Currently, five TE Node Capabilities are defined in [TE-NODE-CAP].
   This document defines a new TE Node Capability:

   - U bit: when set, this flag indicates that the LSR accepts Upstream
   Label Assignment ([RSVP-UPSTREAM]);

   The following bit is added to the OSPF TE Node Capability Descriptor
   TLV:

     Bit      Capabilities
      5        U bit: If set this indicates that the LSR accepts
               Upstream Label Assignment ([RSVP-UPSTREAM]).

   The following bit is added to IS-IS TE Node Capability Descriptor
   sub-TLV:

     Bit      Capabilities
      5        U bit: If set this indicates that the LSR accepts
               Upstream Label Assignment ([RSVP-UPSTREAM]).



























Brehon, et al.            Expires May 22, 2008                  [Page 9]


Internet-Draft              Upstream-Node-Cap              November 2007


5.  Elements of procedure

   *** no new element introduced by this draft ***
















































Brehon, et al.            Expires May 22, 2008                 [Page 10]


Internet-Draft              Upstream-Node-Cap              November 2007


6.  Backward Compatibility

   *** no new element introduced by this draft ***
















































Brehon, et al.            Expires May 22, 2008                 [Page 11]


Internet-Draft              Upstream-Node-Cap              November 2007


7.  Security Considerations

   *** no new element introduced by this draft ***
















































Brehon, et al.            Expires May 22, 2008                 [Page 12]


Internet-Draft              Upstream-Node-Cap              November 2007


8.  IANA considerations

8.1.  Capability Registry

   [OSPF-CAP] defines a new code point registry for TLVs carried in the
   Router Information LSA defined in [OSPF-CAP].

   IANA is requested to make assignments for the TE node capability
   defined in this document (see Section 4) using the following
   suggested values, in the Link State Routing TE Capabilities registry:


Bit No.   Name                                                Reference
------+-----------------------------------------------------+----------
   5    U bit: Upstream Label Assignment capability           [This.I-D]




































Brehon, et al.            Expires May 22, 2008                 [Page 13]


Internet-Draft              Upstream-Node-Cap              November 2007


9.  References

   [TE-NODE-CAP] J.P. Vasseur, J.L. Le Roux et al., "IGP Routing
   Protocol Extensions for Discovery of Traffic Engineering Node
   Capabilities", draft-ietf-ccamp-te-node-cap-05, work in progress.

   [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream
   Label Assignment and Context Specific Label Space",
   draft-ietf-mpls-upstream-label-03, work in progress.

   [P2MP-FRR] J. L. Le Roux, R. Aggarwal, J.P. Vasseur, M. Vigoureux,
   "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels",
   draft-ietf-mpls-p2mp-te-bypass-01, work in progress.

   [RSVP-UPSTREAM] R. Aggarwal, J. L. Le Roux, "MPLS Upstream Label
   Assignment for RSVP-TE", draft-ietf-mpls-rsvp-upstream-02, work in
   progress.

   [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.
   "Extensions to RSVP-TE for point-to-multipoint TE LSPs", RFC 4875.

   [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur,
   J.P., "Extensions to OSPF for advertising Optional Router
   Capabilities", draft-ietf-ospf-cap, work in progress.



























Brehon, et al.            Expires May 22, 2008                 [Page 14]


Internet-Draft              Upstream-Node-Cap              November 2007


Authors' Addresses

   Yannick Brehon
   Alcatel-Lucent
   Route de Villejust
   Nozay  91620
   France

   Email: Yannick.Brehon@alcatel-lucent.fr


   Martin Vigoureux
   Alcatel-Lucent
   Route de Villejust
   Nozay  91620
   France

   Email: Martin.Vigoureux@alcatel-lucent.fr


   Laurent Ciavaglia
   Alcatel-Lucent
   Route de Villejust
   Nozay  91620
   France

   Email: Laurent.ciavaglia@alcatel-lucent.fr


   Mohamad Chaitou
   France Telecom
   2, avenue Pierre-Marzin
   Lannion  22307
   France

   Email: Mohamad.Chaitou@orange-ftgroup.com


   Zafar Ali
   Cisco Systems, Inc.
   100 South Main St. #200
   Ann Arbor  MI 48104
   USA

   Email: zali@cisco.com






Brehon, et al.            Expires May 22, 2008                 [Page 15]


Internet-Draft              Upstream-Node-Cap              November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

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


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Brehon, et al.            Expires May 22, 2008                 [Page 16]


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