Network Working Group J.L. Le Roux (Editor)
France Telecom
IETF Internet Draft J.P. Vasseur (Editor)
Cisco System Inc.
Proposed Status: Standard Track Seisho Yasukawa
Expires: January 2007 NTT
July 2006
Routing extensions for discovery of P2MP TE LSP Leaf LSRs
draft-leroux-mpls-p2mp-te-autoleaf-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.
Abstract
The setup of a Point To MultiPoint (P2MP) Traffic Engineering Label
Switched Path (TE LSP) requires the head-end Label Switching Router
(LSR) to be aware of all leaf LSRs. This may require the potentially
cumbersome configuration of potentially a large number of leaf LSRs
on the P2MP TE LSP head-end LSR. Also leaf LSRs may want to
dynamically join or leave a P2MP TE LSP without requiring manual
configuration on the head-end LSR. This document specifies IGP
Le Roux, Vasseur, Yasukawa [Page 1]
Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-01.txt June 2006
routing extensions for ISIS and OSPF so as to provide an automatic
discovery of the set of leaf LSRs members of a P2MP TE-LSP, also
referred to as a P2MP TE Group, in order to automate the creation and
modification of such P2MP TE LSP.
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.
Table of Contents
1. Terminology.................................................2
2. Introduction................................................2
3. P2MP TE Group...............................................3
3.1. Description.................................................3
3.2. Required Information........................................3
4. P2MP-TE-GROUP TLV formats...................................4
4.1. OSPF P2MP-TE-GROUP TLV format...............................4
4.2. IS-IS P2MP-TE-GROUP TLV format..............................5
5. Elements of procedure.......................................6
5.1. OSPF........................................................6
5.2. ISIS........................................................7
6. Backward compatibility......................................8
7. IANA Considerations.........................................8
7.1. OSPF........................................................8
7.2. ISIS........................................................8
8. Security Considerations.....................................8
9. References..................................................8
9.1. Normative references........................................8
9.2. Informative References......................................9
10. Authors' Address...........................................10
11. Intellectual Property Statement............................10
1. Terminology
This document uses terminologies defined in [RFC3031], [RFC3209],
[RFC4461], and [P2MP-RSVP-TE].
2. Introduction
[P2MP-RSVP] defines RSVP-TE extensions for setting up P2MP TE LSPs,
with one ingress LSR and a set of one or more egress LSRs (leaves).
The setup of a P2MP TE LSP requires the ingress LSR to be aware of
all leaf LSRs. In operational networks P2MP TE LSPs may comprise a
significant number of leaf LSRs and this may require cumbersome
configuration on the Ingress LSR, prone to misconfiguration.
Also Leaf LSRs may desire to dynamically join or leave a P2MP TE LSP.
Le Roux, Vasseur, Yasukawa [Page 2]
Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-01.txt June 2006
Hence an automatic mechanism for discovering the leaf LSRs that want
to join or leave a P2MP TE LSP is desired.
This document specifies IGP (OSPF and IS-IS) extensions so as to
automatically discover the leaf LSRs of a P2MP TE LSP also referred
to as a "P2MP TE Group". Note that the mechanism(s) needed for the
dynamic creation of P2MP TE LSPs and dynamic Leaf addition/removal
(grafting/pruning), is implementation specific and outside the scope
of this document. An implementation should take special care of
implementing the appropriate dampening mechanisms to avoid any
unacceptable impact on the IGP scalability.
Routing extensions have been defined in [OSPF-CAP] and [ISIS-CAP] in
order to advertise router capabilities. This document specifies IGP
(OSPF and ISIS) P2MP TE Group TLVs allowing for the automatic
discovery of a P2MP TE LSP leaf LSR, to be carried in the OSPF Router
Information LSA [OSPF-CAP] and ISIS Router Capability TLV [ISIS-CAP].
3. P2MP TE Group
3.1. Description
A P2MP TE Group is defined as the set of leaf LSRs of a P2MP TE LSP.
Routing extensions are specified in this document allowing for
dynamic discovery of the P2MP TE Group members. Procedures are also
specified for a member to join or leave a P2MP TE group.
An LSR may belong to multiple P2MP TE Group.
3.2. Required Information
This document specifies a P2MP-TE-GROUP TLV that indicates the set of
P2MP TE Group(s) an LSR belongs to. For each P2MP TE group membership
announced by an LSR, the P2MP-TE-GROUP TLV advertises the following
information:
- A P2MP TE group number identifying the P2MP TE group the LSR
belongs to;
- A Leaf LSR address used by the Ingress LSR to signal a S2L sub-LSP
to the advertising LSR for this P2MP TE group.
Le Roux, Vasseur, Yasukawa [Page 3]
Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-01.txt June 2006
4. P2MP-TE-GROUP TLV formats
4.1. OSPF P2MP-TE-GROUP TLV format
The format of the OSPF P2MP-TE-GROUP TLV is the same as the TLV
format used by the Traffic Engineering Extensions to OSPF [OSPF-TE].
That is, the TLV is composed of 2 octets for the type, 2 octets
specifying the TLV length and a value field. The TLV is padded to
four-octet alignment; padding is not included in the length field (so
a three octet value would have a length of three, but the total size
of the TLV would be eight octets). The OSPF P2MP-TE-GROUP TLV is used
to advertise the desire of an LSR to join/leave a given P2MP TE LSP.
The OSPF IPv4 P2MP-TE-GROUP TLV (advertised in an OSPF router
information LSA defined in [OSPF-CAP]) has the following format:
TYPE: To be assigned by IANA (Suggested Value: 5)
LENGTH: Variable
VALUE:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP TE Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf LSR IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - IPv4 P2MP-TE-GROUP TLV format
The OSPF IPv6 P2MP-TE-GROUP TLV (advertised in an OSPF router
information LSA defined in [OSPF-CAP]) has the following format:
TYPE: To be assigned by IANA (Suggested Value: 6)
LENGTH: Variable
VALUE:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP TE Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Leaf LSR IPv6 address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - IPv6 P2MP-TE-GROUP TLV format
Le Roux, Vasseur, Yasukawa [Page 4]
Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-01.txt June 2006
For each P2MP TE group announced by the LSR, the P2MP-TE-GROUP TLV
comprises:
- A P2MP TE group number that identifies the P2MP TE group.
- A Leaf-LSR address: an IPv4 or IPv6 IP address to be used as S2L
sub-LSP destination address for the corresponding P2MP TE group.
4.2. IS-IS P2MP-TE-GROUP TLV format
The IS-IS P2MP-TE-GROUP TLV is composed of 1 octet for the
type, 1 octet specifying the TLV length and a value field. The
format of the P2MP-TE-GROUP TLV is identical to the TLV format used
by the Traffic Engineering Extensions for IS-IS [RFC3784].
The ISIS P2MP-TE-GROUP TLV is used to advertise the desire of an LSR
to join/leave a given P2MP TE LSP.
The ISIS IPv4 P2MP-TE-GROUP TLV (advertised in an IS-IS Router
Capability TLV defined in [ISIS-CAP]) has the following format:
TYPE: To be assigned by IANA (Suggested Value: 5)
LENGTH: Variable
VALUE:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP TE Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf LSR IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - IPv4 P2MP-TE-GROUP TLV format
The ISIS IPv6 P2MP-TE-GROUP TLV (advertised in an OSPF router
information LSA defined in [OSPF-CAP]) has the following format:
TYPE: To be assigned by IANA (Suggested Value: 6)
LENGTH: Variable
VALUE:
Le Roux, Vasseur, Yasukawa [Page 5]
Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-01.txt June 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP TE Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Leaf LSR IPv6 address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - IPv6 P2MP-TE-GROUP TLV format
For each P2MP TE group announced by the LSR, the ISIS P2MP-TE-GROUP
TLV comprises:
- A P2MP TE group number that identifies the P2MP TE group.
- A Leaf-LSR address: an IPv4 or IPv6 IP address to be used as S2L
sub-LSP destination address, for the corresponding P2MP TE group.
5. Elements of procedure
5.1. OSPF
The P2MP-TE-GROUP TLV is advertised, within an OSPFv2 Router
Information LSA (Opaque type of 4 and Opaque ID of 0) or OSPFv3
Router information LSA (function code of 12) which are defined in
[OSPF-CAP]. As such, elements of procedure are inherited from those
defined in [OSPF-CAP].
The P2MP-TE-GROUP TLV is OPTIONAL and must at most appear once in an
OSPF Router Information LSA.
In OSPFv2 the flooding scope is controlled by the opaque LSA type (as
defined in [RFC2370]) and in OSPFv3 by the S1/S2 bits (as defined in
[OSPFv3]). The P2MP-TE-GROUP TLV flooding scope will depend on the
P2MP TE LSP Ingress LSR and leaf LSRs location:
- If the Ingress LSR and generating LSR are located within the same
area, the P2MP-TE-GROUP TLV MUST be generated within an OSPFV2
type 10 Router Information LSA or an OSPFV3 Router Information LSA
with the S1 bit set and the S2 bit cleared.
- If the Ingress LSR and generating LSRs are located within distinct
areas, the P2MP-TE-GROUP TLV MUST be generated within an
OSPFV2 type 11 Router Information LSA or an OSPFV3 Router
Information LSA with the S1 bit cleared and the S2 bit set.
Le Roux, Vasseur, Yasukawa [Page 6]
Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-01.txt June 2006
A router MUST originate a new OSPF router information LSA whenever
the content of the any of the advertised P2MP-TE-GROUP TLV changes or
whenever required by the regular OSPF procedure (LSA refresh (every
LSRefreshTime)). If an LSR desires to join or leave a particular P2MP
TE group, it MUST originate a new OSPF Router Information LSA
comprising the updated P2MP-TE-GROUP TLV. In the case of a join a new
entry will be added to the P2MP-TE-GROUP TLV; conversely if the LSR
leaves a P2MP TE group the corresponding entry will be removed from
the P2MP-TE-GROUP TLV. Note that both operations can be performed in
the context of a single refresh. An implementation SHOULD be able to
detect any change to a previously received P2MP-TE-GROUP TLV from a
specific LSR.
*Editorial note: Discussion on the number of groups and frequency of
changes to be added*
5.2. ISIS
The P2MP-TE-GROUP TLV is advertised, within the IS-IS Router
CAPABILITY TLV defined in [ISIS-CAP]. As such, elements of procedure
are inherited from those defined in [ISIS-CAP].
The P2MP-TE-GROUP TLV is OPTIONAL and must at most appear once in an
ISIS Router CAPABILITY TLV.
The P2MP-TE-GROUP TLV flooding scope will depend on the P2MP TE LSP
Ingress LSR and leaf LSRs location:
- If the Ingress LSR and generating LSR are located within a single
IS-IS area/level, the P2MP-TE-GROUP TLV MUST not be leaked across
IS-IS level/area and the S flag of the Router CAPABILITY TLV MUST
be cleared.
- If the Ingress LSR and generating LSRs are located within distinct
IS-IS area/level, the P2MP-TE-GROUP TLV MUST be leaked across IS-
IS level/area and the S flag of the Router CAPABILITY TLV MUST be
set.
An IS-IS router MUST originate a new IS-IS LSP whenever the content
of the any of the advertised P2MP-TE-GROUP TLV changes or whenever
required by the regular IS-IS procedure (LSP refresh). If an LSR
desires to join or leave a particular P2MP TE group, it MUST
originate a new LSP comprising the updated P2MP-TE-GROUP TLV. In the
case of a join a new entry will be added to the P2MP-TE-GROUP TLV;
conversely if the LSR leaves a P2MP TE group the corresponding entry
will be removed from the P2MP-TE-GROUP TLV. Note that both operations
can be performed in the context of a single refresh. An
implementation SHOULD be able to detect any change to a previously
received P2MP-TE-GROUP TLV from a specific LSR.
*Editorial note: Discussion on the number of groups and frequency of
changes to be added*
Le Roux, Vasseur, Yasukawa [Page 7]
Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-01.txt June 2006
6. Backward compatibility
The P2MP-TE-GROUP TLVs defined in this document do not introduce any
interoperability issue.
For OSPF, a router not supporting the P2MP-TE-GROUP TLV MUST just
silently ignore the TLV as specified in [OSPF-CAP].
For IS-IS a router not supporting the P2MP-TE-GROUP TLV MUST just
silently ignore the TLV as specified in [IS-IS-CAP].
7. IANA Considerations
7.1. OSPF
IANA is in charge of the assignment of TLV code points for the Router
Information LSA defined in [OSPF-CAP].
IANA will assign a new codepoint for the P2MP-TE-GROUP TLV defined in
this document and carried within the Router Information LSA.
IPv4 P2MP-TE-GROUP TLV (suggested value=5)
IPv6 P2MP-TE-GROUP TLV (suggested value=6)
7.2. ISIS
IANA is in charge of the assignment of TLV code points for the IS-IS
Router CAPABILITY TLV defined in [ISIS-CAP].
IANA will assign a new codepoint for the P2MP-TE-GROUP TLV defined in
this document and carried within the IS-IS Router CAPABILITY TLV.
IPv4 P2MP-TE-GROUP TLV (suggested value=5)
IPv6 P2MP-TE-GROUP TLV (suggested value=6)
8. Security Considerations
No new security issues are raised in this document.
9. References
9.1. Normative references
[RFC] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Le Roux, Vasseur, Yasukawa [Page 8]
Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-01.txt June 2006
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
[BCP79] Bradner, S., "Intellectual Property Rights in IETF
Technology", RFC 3979, March 2005.
[OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPF-v3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998.
[IS-IS] "Intermediate System to Intermediate System Intra-Domain
Routing Exchange Protocol " ISO 10589.
[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", RFC 3630, September 2003.
[IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", RFC 3784, June 2004.
[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.
[IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising
router information", draft-ietf-isis-caps, work in progress.
[RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to
RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls-rsvp-te-
p2mp, work in progress.
9.2. Informative References
[P2MP-REQ] Yasukawa, S., et. al., "Signaling Requirements for Point
to Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 2006.
Le Roux, Vasseur, Yasukawa [Page 9]
Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-01.txt June 2006
10. Authors' Address
Jean-Louis Le Roux (Editor)
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: jeanlouis.leroux@francetelecom.com
Jean-Philippe Vasseur (Editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Seisho Yasukawa
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585,
Japan
11. 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
Le Roux, Vasseur, Yasukawa [Page 10]
Internet Draft draft-leroux-mpls-p2mp-te-autoleaf-01.txt June 2006
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 Internet Society (2006). 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.
Le Roux, Vasseur, Yasukawa [Page 11]