Internet DRAFT - draft-brevigcia-ccamp-mpls-upstream-node-cap
draft-brevigcia-ccamp-mpls-upstream-node-cap
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]
