wdiff draft-leroux-mpls-p2mp-te-autoleaf-01.txt draft-leroux-mpls-p2mp-te-autoleaf-02.txt

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 April 2007 NTT

July
Martin Vigoureux
Alcatel

October 2006

IGP Routing extensions for discovery of P2MP TE LSP Leaf LSRs

draft-leroux-mpls-p2mp-te-autoleaf-01.txt

draft-leroux-mpls-p2mp-te-autoleaf-02.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

In various situations, such as TV broadcasting with several regional
sources, it is required to setup of a Point To MultiPoint series of Point-To-MultiPoint
(P2MP) Traffic Engineering Label Switched Path Paths (TE LSP) requires the LSPs) between a
set of head-end Label Switching Router
(LSR) Routers (LSRs) and a group of leaf
LSRs referred to as a Leaf Group. Setting up such a series of P2MP TE
LSPs requires for the set of head-end LSRs to be aware of all leaf LSRs. This
LSRs, which may require lead to the potentially cumbersome configuration of potentially a potentially
large number of leaf LSRs on the P2MP TE LSP each head-end LSR. Also LSRs. Furthermore leaf
LSRs may want to dynamically join or leave a P2MP TE LSP Leaf Group without
requiring manual configuration on the head-end LSR. LSRs. This document
specifies IGP routing extensions for ISIS IS-IS 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 Leaf
Group, in order to automate the creation and modification of such a series
of P2MP TE LSP. TE-LSPs.

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 Note........................................................3
2. Introduction................................................2 Terminology.................................................3
3. P2MP TE Group...............................................3
3.1. Description.................................................3
3.2. Required Information........................................3 Introduction................................................3
4. P2MP-TE-GROUP TLV formats...................................4 Leaf Group..................................................4
4.1. Description.................................................4
4.2. Required Information........................................4
5. LEAF-GROUP TLV formats......................................4
5.1. OSPF P2MP-TE-GROUP LEAF-GROUP TLV format...............................4
4.2. format..................................4
5.2. IS-IS P2MP-TE-GROUP LEAF-GROUP TLV format..............................5
5. format.................................6
6. Elements of procedure.......................................6
5.1. OSPF........................................................6
5.2. ISIS........................................................7
6. Backward compatibility......................................8 procedure.......................................7
6.1. OSPF........................................................7
6.2. IS-IS.......................................................8
7. IANA Considerations.........................................8
7.1. OSPF........................................................8
7.2. ISIS........................................................8 Backward compatibility......................................9
8. Security Considerations.....................................8 IANA Considerations.........................................9
8.1. OSPF........................................................9
8.2. IS-IS.......................................................9
9. References..................................................8
9.1. Security Considerations....................................10
10. References.................................................10
10.1. Normative references........................................8
9.2. references.......................................10
10.2. Informative References......................................9
10. Authors' Address...........................................10 References.....................................11
11. Authors' Address...........................................11
12. Intellectual Property Statement............................10 Statement............................12

1. Note

This document defines the concept of “Auto-leaf” along with the
required IS-IS and OSPF extensions that may be described in separate
documents at a later stage.

2. Terminology

This document uses terminologies defined in [RFC3031], [RFC3209],
[RFC4461], and [P2MP-RSVP-TE].

2. [RSVP-P2MP-TE].

3. Introduction

[P2MP-RSVP]

[RSVP-P2MP-TE] defines RSVP-TE extensions for setting up P2MP TE
LSPs, with one ingress head-end LSR and a set of one or more egress leaf LSRs
(leaves).

In various situations, such as for instance TV broadcasting with
several non collocated sources, it is required to setup a series of
P2MP TE LSPs between a set of head-end LSRs and a common group of
leaf LSRs, that is a series of P2MP TE-LSPs with distinct head-end
LSRs and the same group of leaf LSRs. Such a group of leaf LSRs is
referred to as a "P2MP Leaf Group". The setup of such a P2MP TE LSP
series requires the ingress LSR for each head-end LSRs to be aware of all leaf LSRs. In operational networks LSRs
in the P2MP TE LSPs may comprise Leaf Group. It is not uncommon for a P2MP Leaf Group to
contain a significant number of leaf LSRs LSRs, and this there may require be a
potentially large number of head-end LSRs. In such situations, this
requires cumbersome configuration of all leaf LSRs on the Ingress LSR, each head-end
LSRs, prone to misconfiguration.

Also

Furthermore, Leaf LSRs may desire to dynamically join or leave a P2MP TE LSP.
Leaf Group.

Hence an automatic mechanism for discovering allowing head-end LSRs to discover the
leaf LSRs that want willing to join or leave a P2MP TE LSP is desired. Leaf Group would undoubtedly
ease the configuration task.

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". Leaf Group. Note that the mechanism(s)
mechanisms needed for the dynamic creation of P2MP TE LSPs and
dynamic Leaf addition/removal (grafting/pruning), is are 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 Leaf Group TLVs allowing for the automatic
discovery of a P2MP TE LSP leaf LSR, an LSR to advertise its
desire to join/leave one or more Leaf Group(s), to be carried in the
OSPF Router Information LSA [OSPF-CAP] and ISIS IS-IS Router Capability
TLV [ISIS-CAP].

3. This allows the automatic creation and modification
of a series of P2MP TE LSPs without manual intervention.

4. Leaf Group

3.1.

4.1. Description

A P2MP TE Leaf Group is defined as the set a group of leaf LSRs LSRs, which are leaves of a
series of one or more P2MP TE LSP. LSPs. Routing extensions are specified
in this document allowing for dynamic discovery of the P2MP TE Leaf Group
members. Procedures are also specified for a member to join or leave
a P2MP TE Leaf group.

An LSR may belong to multiple P2MP TE Group.

3.2. Leaf Groups.

4.2. Required Information

This document specifies a P2MP-TE-GROUP LEAF-GROUP TLV that indicates the set of
P2MP TE
Leaf Group(s) an LSR belongs to. For each P2MP TE group Leaf Group membership
announced by an LSR, the P2MP-TE-GROUP LEAF-GROUP TLV advertises the following
information:

- A P2MP TE group is used to advertise a Leaf
Group number identifying the P2MP TE Leaf 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.

4. P2MP-TE-GROUP to.

5. LEAF-GROUP TLV formats

4.1.

5.1. OSPF P2MP-TE-GROUP LEAF-GROUP TLV format

The format of the OSPF P2MP-TE-GROUP LEAF-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 zero padded to
four-octet 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 LEAF-GROUP TLV is used to advertise the desire of an LSR to
join/leave a given P2MP TE LSP. set of one or more Leaf Group(s).

The OSPF IPv4 P2MP-TE-GROUP LEAF-GROUP TLV (advertised in an OSPF router
information OSPFv2 Router
Information LSA defined in [OSPF-CAP]) has the following format:

TYPE: To be assigned by IANA (Suggested Value: 5)
LENGTH: Variable (>=8, multiple of 4)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf Group Number 1 |
// //
| Leaf Group Number N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 - IPv4 P2MP-TE-GROUP LEAF-GROUP TLV format

The OSPF IPv6 P2MP-TE-GROUP LEAF-GROUP TLV (advertised in an OSPF router
information OSPFv3 Router
Information LSA defined in [OSPF-CAP]) has the following format:

TYPE: To be assigned by IANA (Suggested Value: 6)
LENGTH: Variable (>= 20, multiple of 4)
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf Group Number 1 |
// //
| Leaf Group Number N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2 - IPv6 P2MP-TE-GROUP LEAF-GROUP TLV format

For each P2MP TE group announced by the LSR, the P2MP-TE-GROUP

The LEAF-GROUP TLV
comprises:

- A P2MP TE group number that identifies the P2MP TE group. contains:

- A Leaf-LSR address: an IPv4 or IPv6 IP address to be used as S2L
sub-LSP destination address for (defined in [RSVP-P2MP-TE]).
- A set of one or more Leaf Group number(s), encoded with 32 bit
integers that identify the corresponding P2MP TE group.

4.2. Leaf Group(s) the LSR belongs to.

5.2. IS-IS P2MP-TE-GROUP LEAF-GROUP TLV format

The IS-IS P2MP-TE-GROUP LEAF-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 LEAF-
GROUP TLV is identical to the TLV format used by the Traffic
Engineering Extensions for IS-IS [RFC3784].

The ISIS P2MP-TE-GROUP LEAF-GROUP TLV is used to advertise the desire of an LSR to
join/leave a given P2MP TE LSP. set of one or more Leaf Groups.

The ISIS IPv4 P2MP-TE-GROUP LEAF-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 (>=8, multiple of 4)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf Group Number 1 |
// //
| Leaf Group Number N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3 - IPv4 P2MP-TE-GROUP LEAF-GROUP TLV format

The ISIS IPv6 P2MP-TE-GROUP LEAF-GROUP TLV (advertised in an OSPF IS-IS router
information LSA defined in [OSPF-CAP]) [ISIS-CAP]) has the following format:

TYPE: To be assigned by IANA (Suggested Value: 6)
LENGTH: Variable
VALUE:

Figure 4 - IPv6 P2MP-TE-GROUP LEAF-GROUP TLV format

For each P2MP TE group announced by the LSR, the ISIS P2MP-TE-GROUP

The P2MP-LEAF-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 address (defined in [RSVP-P2MP-TE]).
- A set of one or more Leaf Group number(s), encoded with 32
bit integers that identifies the corresponding P2MP TE group.

5. Leaf Group(s) the LSR
belongs to.

6. Elements of procedure

5.1.

6.1. OSPF

The P2MP-TE-GROUP LEAF-GROUP TLV is advertised, carried 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 that are defined in [OSPF-CAP]. As such,
elements of procedure are inherited from those defined in [OSPF-CAP].

The P2MP-TE-GROUP LEAF-GROUP TLV is OPTIONAL and must at most appear once in an OPTIONAL. An OSPF Router Information LSA. LSA may
comprise zero one or more LEAF-GROUP TLVs. Several TLVs are used when
distinct destination addresses have to be used for distinct Leaf
Groups.

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 LEAF-GROUP TLV flooding scope will depend on be determined according to the
location of the head-end LSR(s) for the P2MP TE LSP Ingress LSR related to the
LEAF GROUP and leaf LSRs location: the location of the Leaf LSR originating the LEAF-
GROUP TLV:

- If the Ingress LSR head-end LSR(s) and generating leaf LSR originating the P2MP-LEAF-
GROUP TLV are located within the same area, the P2MP-TE-GROUP LEAF-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 head-end LSR(s) and generating leaf LSRs originating the LEAF-GROUP
TLV are located within distinct
areas, areas the P2MP-TE-GROUP LEAF-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.

A router MUST originate a new OSPF router information Router Information LSA whenever
the content of the any of the advertised P2MP-TE-GROUP LEAF-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 Leaf
group, it MUST originate a new OSPF Router Information LSA
comprising containing
the updated P2MP-TE-GROUP LEAF-GROUP TLV. In the case of a join a new entry will be
added to the P2MP-TE-GROUP LEAF-GROUP TLV; conversely conversely, if the LSR leaves a P2MP TE group Leaf
Group the corresponding entry will be removed from the P2MP-TE-GROUP LEAF-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 LEAF-GROUP TLV from a specific LSR.

*Editorial note: Discussion on the

A P2MP LSP is likely to aggregate a large number of groups multicast
channels and frequency hence the number of
changes Leaf Groups an LSR belongs to is
expected to be added*

5.2. ISIS very small, typically less than 10. Otherwise, in the
case of a large number of Leaf Groups care should be given to the
relevance of using an IGP-based discovery mechanism.

Moreover, as spelt out in [RFC4461], the dynamics of the P2MP LSP is
likely to be relatively small. A working figure for an established
P2MP TE LSP is less than 10% churn per day; that is, a relatively
slow rate of churn. Nevertheless appropriate rate limiting and
dampening mechanisms SHOULD be implemented so as to avoid any
unacceptable impact on IGP scalability. The P2MP-TE-GROUP dampening and rate
limiting algorithms in use are outside of the scope of this document.

6.2. IS-IS

The LEAF-GROUP TLV is advertised, carried within the IS-IS Router CAPABILITY TLV
that is defined in [ISIS-CAP]. As such, elements of procedure are
inherited from those defined in [ISIS-CAP].

The P2MP-TE-GROUP LEAF-GROUP TLV is OPTIONAL and must at most appear once in an
ISIS OPTIONAL. An IS-IS Router CAPABILITY TLV. TLV may
comprise zero one or more LEAF-GROUP TLVs. Several TVLs are used when
distinct destination addresses have to be used for distinct Leaf
Groups.

The P2MP-TE-GROUP LEAF-GROUP TLV flooding scope will depend on the P2MP TE LSP
Ingress LSR head-end
LSR(s) and leaf LSRs generating LSR location:

- If the Ingress LSR head-end LSR(s) and generating LSR are located within a
single IS-IS area/level, the P2MP-TE-GROUP LEAF-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 head-end LSR(s) and generating LSRs LSR are located within
distinct IS-IS area/level, the P2MP-TE-GROUP LEAF-GROUP TLV MUST be leaked
across IS-
IS 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 LEAF-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, Leaf Group, it MUST originate a new IS-IS LSP comprising
containing the updated P2MP-TE-GROUP LEAF-GROUP TLV. In the case of a join a new
entry will be added to the P2MP-TE-GROUP LEAF-GROUP TLV;
conversely conversely, if the LSR
leaves a P2MP TE group Leaf Group the corresponding entry will be removed from the P2MP-TE-GROUP
LEAF-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 LEAF-GROUP TLV from a
specific LSR.

*Editorial note: Discussion on

A P2MP LSP is likely to aggregate a large number of multicast
channels and hence the number of Leaf groups and frequency an LSR belongs to is
expected to be very small, typically less than 10. Otherwise, in the
case of
changes a large number of Leaf Groups care should be given to the
relevance of using an IGP-based discovery mechanism.

Moreover, as spelt out in [RFC4461], the dynamics of the P2MP LSP is
likely to be added*

6. relatively small. A working figure for an established
P2MP TE LSP is less than 10% churn per day; that is, a relatively
slow rate of churn. Nevertheless appropriate rate limiting and
dampening mechanisms SHOULD be implemented so as to avoid any
unacceptable impact on IGP scalability. The dampening and rate
limiting algorithms in use are outside of the scope of this document.

7. Backward compatibility

The P2MP-TE-GROUP LEAF-GROUP TLVs defined in this document do not introduce any
interoperability issue.
For OSPF, a router not supporting the P2MP-TE-GROUP LEAF-GROUP TLV MUST just
silently ignore the TLV as specified in [OSPF-CAP].
For IS-IS a router not supporting the P2MP-TE-GROUP LEAF-GROUP TLV MUST just
silently ignore the TLV as specified in [IS-IS-CAP].

8. IANA Considerations

7.1.

8.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 LEAF-GROUP TLVs defined in
this document and carried within the Router Information LSA.

IPv4 P2MP-TE-GROUP LEAF-GROUP TLV (suggested value=5)

IPv6 P2MP-TE-GROUP LEAF-GROUP TLV (suggested value=6)

7.2. ISIS

8.2. IS-IS

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 LEAF-GROUP TLVs defined in
this document and carried within the IS-IS Router CAPABILITY TLV.

IPv4 P2MP-TE-GROUP LEAF-GROUP TLV (suggested value=5)

IPv6 P2MP-TE-GROUP LEAF-GROUP TLV (suggested value=6)

9. Security Considerations

No new security issues are raised

This document specifies the content of the LEAF GROUP TLV in IS-IS
and OSPF, to be used for automating the setup of P2MP TE-LSPs. As
this document.

9. References

9.1. Normative references

[RFC] Bradner, S., "Key words TLV is not used for use in RFCs SPF computation or normal routing, the
extensions specified here have no direct effect on IP routing.
Tampering with this TLV may have an effect on the configuration of
P2MP TE-LSP. Mechanisms defined to indicate
requirements levels", RFC 2119, March 1997.

[RFC2119] Bradner, S., "Key words secure IS-IS Link State PDUs
[ISIS-HMAC], OSPF LSAs [OSPF-SIG], and their TLVs, can be used to
secure this TLV as well. DoS attacks that would consist of
advertising a considerable number of Leaf Groups would not lead to
the generation of the corresponding P2MP TE LSPs since this would
also require for use in RFCs other LSRs acting as head-end to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. be also configured
with matching Leaf Groups.

10. References

10.1. Normative references

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

[RSVP-P2MP-TE] 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.

10.2. Informative References

[P2MP-REQ]

[RFC4461] Yasukawa, S., et. al., "Signaling Requirements for Point to
Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 2006.

10.

11. Authors' Address Addresses

Jean-Louis Le Roux (Editor)
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: jeanlouis.leroux@francetelecom.com

Jean-Philippe

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

Martin Vigoureux
Alcatel
Route de Nozay, 91461 Marcoussis cedex, France
Phone: +33 (0)1 69 63 18 52
Email: martin.vigoureux@alcatel.fr

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