Network Working Group Y. Brehon
Internet-Draft M. Vigoureux
Intended status: Informational L. Ciavaglia
Expires: May 15, 2008 Alcatel-Lucent
November 12, 2007
IGP Routing Protocol Extensions for Discovery of Upstream Label
Assignment Node Capability
draft-brevigcia-ccamp-mpls-upstream-node-cap-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 May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Brehon, et al. Expires May 15, 2008 [Page 1]
Internet-Draft Upstream-Node-Cap November 2007
Abstract
This document proposes to extend [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 into P2MP Tunnels 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 15, 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. TE Node Capability Descriptor TLV formats . . . . . . . . . . 10
5.1. OSPF TE Node Capability Descriptor TLV format . . . . . . 10
5.2. IS-IS TE Node Capability Descriptor sub-TLV format . . . . 10
6. Elements of procedure . . . . . . . . . . . . . . . . . . . . 12
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Capability Registry . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Brehon, et al. Expires May 15, 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 15, 2008 [Page 4]
Internet-Draft Upstream-Node-Cap November 2007
2. Introduction
This document proposes to extend [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 into P2MP Tunnels is a desirable
traffic-engineering feature. P2MP Fast ReRoute (FRR) [P2MP-FRR] is
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. Using 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 it receives based on the value of this label and according
to the emitting node (i.e., defining a per-upstream-neighbor label
space) or according to the value of the P2MP Tunnel label (i.e.,
defining a per-tunnel label space).
[RSVP-UPSTREAM] and [LDP-UPSTREAM] define extensions to [RFC4875] and
[MLDP] 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 in case all the egress nodes do
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
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 protocols used for
Brehon, et al. Expires May 15, 2008 [Page 5]
Internet-Draft Upstream-Node-Cap November 2007
establishing the LSPs (LDP and/or 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.
*** Open for discussion ***
Two additional bit flags can be defined to indicate the type of
context label space the egress node accepts.
The bit flag (N) enables a node to advertise its capability to
maintain and process per-upstream-neighbor context-specific labels.
The bit flag (T) enables a node to advertise its capability to
maintain and process per-tunnel-neighbor context-specific labels.
***
Brehon, et al. Expires May 15, 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
Brehon, et al. Expires May 15, 2008 [Page 7]
Internet-Draft Upstream-Node-Cap November 2007
crucial 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 a scalable deployment of the P2MP
mechanisms, protection mechanisms to work properly, and provides for
less failure during the signaling phase.
Brehon, et al. Expires May 15, 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], [LDP-UPSTREAM]);
*** Open for discussion ***
- N bit: when set, this flag indicates that the LSR accepts per-
upstream-neighbor label space.
- T bit: when set, this flag indicates that the LSR accepts per-
tunnel label space.
***
Brehon, et al. Expires May 15, 2008 [Page 9]
Internet-Draft Upstream-Node-Cap November 2007
5. TE Node Capability Descriptor TLV formats
5.1. OSPF TE Node Capability Descriptor TLV format
The OSPF TE Node Capability Descriptor TLV is a variable length TLV
that contains a series of bit flags, where each bit correspond to a
TE node capability.
The OSPF TE Node Capability Descriptor TLV is carried within an OSPF
Router Information LSA which is defined in [OSPF-CAP].
The format of the OSPF TE Node Capability Descriptor TLV is the same
as the TLV format used by the Traffic Engineering Extensions to OSPF
[RFC3630]. That is, the TLV is composed of 2 octets for the type, 2
octets specifying the length of the value field and a value field.
The OSPF TE Node Capability Descriptor TLV has the following format:
TYPE: Assigned by IANA - see Section 8.1.
LENGTH: Variable (multiple of 4).
VALUE: Array of units of 32 flags numbered from the most significant
bit as bit zero, where each bit represents a TE node capability.
The following bits are added:
Bit Capabilities
5 U bit: If set this indicates that the LSR accepts Upstream Label
Assignment ([RSVP-UPSTREAM], [LDP-UPSTREAM]).
*** Open for discussion ***
6 N bit: If set, this indicates that the LSR accepts per-upstream-
neighbor label space.
7 T bit: If set, this indicates that the LSR accepts per-tunnel label
space.
***
x-31 Reserved for future assignments by IANA.
5.2. IS-IS TE Node Capability Descriptor sub-TLV format
The IS-IS TE Node Capability Descriptor sub-TLV is a variable length
sub-TLV that contains a series of bit flags, where each bit
Brehon, et al. Expires May 15, 2008 [Page 10]
Internet-Draft Upstream-Node-Cap November 2007
correspond to a TE node capability.
The IS-IS TE Node Capability Descriptor sub-TLV is carried within an
IS-IS CAPABILITY TLV which is defined in [IS-IS-CAP].
The format of the IS-IS TE Node Capability sub-TLV is the same as the
TLV format used by the Traffic Engineering Extensions to IS-IS
[RFC3784]. That is, the TLV is composed of 1 octet for the type, 1
octet specifying the TLV length and a value field.
The IS-IS TE Node Capability Descriptor sub-TLV has the following
format:
TYPE: Assigned by IANA - see Section 8.1.
LENGTH: Variable (multiple of 4).
VALUE: Array of units of 32 flags numbered from the most significant
bit as bit zero, where each bit represents a TE node capability.
The following bits are added:
Bit Capabilities
5 U bit: If set this indicates that the LSR accepts Upstream Label
Assignment ([RSVP-UPSTREAM], [LDP-UPSTREAM]).
*** Open for discussion ***
6 N bit: If set, this indicates that the LSR accepts per-upstream-
neighbor label space.
7 T bit: If set, this indicates that the LSR accepts per-tunnel label
space.
***
x-31 Reserved for future assignments by IANA.
Brehon, et al. Expires May 15, 2008 [Page 11]
Internet-Draft Upstream-Node-Cap November 2007
6. Elements of procedure
*** no new elements introduced by this draft ***
Brehon, et al. Expires May 15, 2008 [Page 12]
Internet-Draft Upstream-Node-Cap November 2007
7. Backward Compatibility
*** no new elements introduced by this draft ***
Brehon, et al. Expires May 15, 2008 [Page 13]
Internet-Draft Upstream-Node-Cap November 2007
8. Security Considerations
*** no new elements introduced by this draft ***
Brehon, et al. Expires May 15, 2008 [Page 14]
Internet-Draft Upstream-Node-Cap November 2007
9. IANA considerations
9.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 a new codepoint assignment from that
registry for the TE Node Capability Descriptor TLV defined in this
document and carried within the Router Information LSA. The value 1
is suggested. See Section 4.1 of this document.
IANA is requested to make assignments for the (three) TE node
capability(ies) defined in this document (see Sections 4.1 and 4.2)
using the following suggested values, in the Capability Registry for
TE-node capabilities:
Bit No. Name Reference
------+-----------------------------------------------------+----------
6 U bit: Upstream Label Assignment capability [This.I-D]
7 N bit: per-upstream-neighbor label space capability [This.I-D]
8 T bit: per-upstream-neighbor label space capability [This.I-D]
Brehon, et al. Expires May 15, 2008 [Page 15]
Internet-Draft Upstream-Node-Cap November 2007
10. 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-02, 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-01, work in
progress.
[LDP-UPSTREAM] R. Aggarwal, J. L. Le Roux, "MPLS Upstream Label
Assignment for LDP", draft-ietf-mpls-ldp-upstream-01, work in
progress.
[RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.
"Extensions to RSVP-TE for point-to-multipoint TE LSPs", RFC 4875.
[MLDP] Minei, I., Wijnands, I., Thomas, B., "Label Distribution
Protocol Extensions for Point-to-Multipoint and Multipoint-to-
Multipoint Label Switched Paths", Internet Draft,
draft-ietf-mpls-ldp-p2mp-03, work in progress.
Brehon, et al. Expires May 15, 2008 [Page 16]
Internet-Draft Upstream-Node-Cap November 2007
Authors' Addresses
Yannick Brehon
Alcatel-Lucent
Route de Villejust
Nozay, 91620
France
Phone: +33 1 3077 2633
Email: Yannick.Brehon@alcatel-lucent.fr
URI:
Martin Vigoureux
Alcatel-Lucent
Route de Villejust
Nozay, 91620
France
Phone: +33 1 3077 2669
Email: Martin.Vigoureux@alcatel-lucent.fr
URI:
Laurent Ciavaglia
Alcatel-Lucent
Route de Villejust
Nozay, 91620
France
Phone: +33 1 3077 2636
Email: Laurent.ciavaglia@alcatel-lucent.fr
URI:
Brehon, et al. Expires May 15, 2008 [Page 17]
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 15, 2008 [Page 18]