draft-ietf-ccamp-automesh-00.txt   draft-ietf-ccamp-automesh-01.txt 
Networking Working Group JP Vasseur (Ed.) Networking Working Group JP. Vasseur (Editor)
Cisco System Inc. Internet-Draft Cisco Systems, Inc
IETF Internet Draft JL Le Roux (Ed.) Expires: August 9, 2006 JL. Leroux (Editor)
France Telecom France Telecom
S. Yasukawa
Proposed Status: Standard NTT
Expires: May 2006 November 2005 S. Previdi
P. Psenak
Cisco Systems, Inc
P. Mabbey
Comcast
February 5, 2006
Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Routing extensions for discovery of Multiprotocol (MPLS) Label Switch
Router (LSR) Traffic Engineering (TE) mesh membership Router (LSR) Traffic Engineering (TE) mesh membership
draft-ietf-ccamp-automesh-00.txt draft-ietf-ccamp-automesh-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 9, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
Abstract Abstract
The set up of a full mesh of Multi-Protocol Label Switching (MPLS)
Traffic Engineering (TE) Label Switched Path (LSP) among a set of
Label Switch Routers (LSR) is common deployment scenario of MPLS
Traffic Engineering either for bandwidth optimization, bandwidth
guarantees or fast rerouting with MPLS Fast Reroute. Such deployment
may require the configuration of potentially a large number of TE
LSPs (on the order of the square of the number LSRs). This document
specifies IGP routing extensions for ISIS and OSPF so as to provide
an automatic discovery of the set of LSRs members of a mesh in order
to automate the creation of such mesh.
The set up of a full mesh of MPLS TE LSPs among a set of Label Switch Requirements Language
Router (LSR) is common deployment scenario of MPLS Traffic
Engineering either for bandwidth optimization, bandwidth guarantees
or fast rerouting with MPLS Fast Reroute. Such deployment requires
the configuration of potentially a large number of TE LSPs (on the
order of the square of the number LSRs). This document specifies IGP
(OSPF and IS-IS) traffic engineering extensions so as to provide an
automatic discovery of the set of LSRs members of a mesh, leading to
an automatic mechanism to set up TE LSP mesh(es) (also referred to as
a mesh-group in this document).
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Contributors------------------------- 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology-------------------------- 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction------------------------- 3 3. TE Mesh-Group . . . . . . . . . . . . . . . . . . . . . . . . 5
4. TE mesh-roup------------------------- 4 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Description------------------------ 4 3.2. Required Information . . . . . . . . . . . . . . . . . . . 5
4.2. Required Information--------------- 4 4. TE-MESH-GROUP TLV formats . . . . . . . . . . . . . . . . . . 5
5. TE-MESH-GROUP TLV formats------------ 4 4.1. OSPF TE-MESH-GROUP TLV format . . . . . . . . . . . . . . 5
5.1. OSPF TE-MESH-GROUP TLV format------ 5 4.2. IS-IS TE-MESH-GROUP TLV format . . . . . . . . . . . . . . 8
5.2. IS-IS TE-MESH-GROUP TLV format----- 6 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 10
6. Elements of procedure---------------- 7 5.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. OSPF------------------------------- 7 5.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. IS-IS------------------------------ 7 6. Backward compatibility . . . . . . . . . . . . . . . . . . . . 12
7. Backward compatibility--------------- 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations-------------- 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Intellectual Property Statement------ 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgment---------------------- 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. References-------------------------- 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.1. Normative references-------------- 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References------------ 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
12. Editors' Address-------------------- 10 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Contributors
This document was the collective work of several. The text and
content of this document was contributed by the editors and the
co-authors listed below (the contact information for the editors
appears in section 12, and is not repeated below):
Paul Mabey Seisho Yasukawa
Qwest Communications NTT
950 17th street 9-11, Midori-Cho 3-Chome
Denver, CO 80202 Musashino-Shi, Tokyo 180-8585
USA JAPAN
Email: pmabey@qwest.com Email: yasukawa.seisho@lab.ntt.co.jp
Stefano Previdi Peter Psenak
Cisco System, Inc. Cisco System, Inc.
Via del Serafico 200 Pegasus Park
00142 Roma DE Kleetlaan 6A
ITALY 1831, Diegmen
Email: sprevidi@cisco.com BELGIUM
Email: ppsenak@cisco.com
2. Terminology 1. Terminology
Terminology used in this document Terminology used in this document
LSR: Label Switch Router. LSR: Label Switch Router.
TE LSP: Traffic Engineering Label Switched Path. TE LSP: Traffic Engineering Label Switched Path.
TE LSP head-end: head/source of the TE LSP. TE LSP head-end: head/source of the TE LSP.
TE LSP tail-end: tail/destination of the TE LSP. TE LSP tail-end: tail/destination of the TE LSP.
IGP Area: OSPF Area or IS-IS level IGP Area: OSPF area or IS-IS level.
Link State Advertisement: An OSPF LSA or IS-IS LSP
Intra-area TE LSP: TE LSP whose path does not transit across
areas.
Inter-area TE LSP: A TE LSP whose path transits across at least
two different IGP areas.
Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least
two different ASes or sub-ASes (BGP confederations).
3. Introduction 2. Introduction
As of today, there are different approaches in deploying MPLS Traffic There are two well-known approaches in deploying MPLS Traffic
Engineering: Engineering:
(1) The 'systematic' approach consisting of setting up a full (1) The so-called "strategic" approach that consists of setting up a
mesh of TE LSPs between a set of LSRs, full mesh of TE LSPs between a set of LSRs,
(2) The 'by exception' approach whereby a set of TE LSPs are
provisioned on hot spots to alleviate a congestion resulting
for instance from an unexpected traffic growth in some part
of the network.
The set up of a full mesh of MPLS TE LSPs among a set of LSRs is a (2) The so-called "tactical" approach where a set of TE LSPs are
common deployment scenario of MPLS Traffic Engineering either for provisioned on well identified "hot spots" in order to alleviate a
bandwidth optimization, bandwidth guarantees or fast rerouting with congestion resulting for instance from an unexpected traffic growth
MPLS Fast Reroute ([FRR]). Setting up a full mesh of TE LSPs between in some parts of the network.
a set of LSRs requires the configuration of a potentially large
number of TE LSPs on every head-end LSR. The resulting total number
of TE LSP in a full TE mesh of n LSRs is O(n^2). Furthermore, the
addition of any new LSR in the mesh requires the configuration of n
additional TE LSPs on the new LSR and one new TE LSP on every LSR of
the existing mesh terminating to this new LSR, which gives a total of
2*n TE LSPs. Such operation is not only time consuming but also a
risky operation for Service Providers. Hence, a more automatic
mechanism to setting up one or more full meshes of TE LSPs is
desirable and requires the ability to automatically discover the LSRs
that belong to the mesh.
MPLS Traffic Engineering (MPLS-TE) routing ([IS-IS-TE], [OSPF-TE]) The set up of a full mesh of TE LSPs among a set of LSRs is a common
relies on extensions to link state IGP routing protocols ([OSPF], deployment scenario of MPLS Traffic Engineering either for bandwidth
[IS-IS]) in order to carry Traffic Engineering link information used optimization, bandwidth guarantees or fast rerouting with MPLS Fast
for constraint based routing. Generalized MPLS (GMPLS) related Reroute. Setting up a full mesh of TE LSPs between N LSRs requires
routing extensions are defined in [IS-IS-G] and [OSPF-G]. the configuration of a potentially large number of TE LSPs (O(N^2)).
Furthermore, the addition of any new LSR in the mesh requires the
configuration of N additional TE LSPs on the new LSR and one new TE
LSP on every LSR of the existing mesh destined to this new LSR, which
gives a total of 2*N TE LSPs to be configured. Such operation is not
only time consuming but also a risky operation (prone to
misconfiguration) for Service Providers. Hence, an automatic
mechanism for setting up TE LSPs meshes is desirable and requires the
ability to automatically discover the LSRs that belong to the mesh.
This document specifies routing extensions so as to automatically
discover the members of a mesh, also referred to as a "TE mesh-
group". Note that the mechanism(s) needed for the dynamic creation
of TE LSPs is implementation specific and outside the scope of this
document.
Further routing extensions have been defined in [OSPF-CAPS] and [IS- Routing extensions have been defined in [I-D.ietf-ospf-cap] and
IS-CAPS] so as to advertise router capabilities. This document [I-D.ietf-isis-caps] in order to advertise router capabilities. This
specifies IGP (OSPF and IS-IS) traffic engineering capability TLVs in document specifies IGP (OSPF and IS-IS) TE Mesh Group TLVs allowing
order to provide a mechanism to automatically discover the LSR for the automatic discovery of a TE LSP mesh members, to be carried
members of a mesh, leading to an automatic mechanism to set up TE LSP in the OSPF Router Information LSA [I-D.ietf-ospf-cap] and ISIS
mesh (also referred to as a mesh-group in this document) in a Router Capability TLV [I-D.ietf-isis-caps]. The routing extensions
network. The routing extensions specified in this document provide specified in this document provide the ability to signal multiple TE
the ability to signal multiple TE meshes whereby an LSR can belong to mesh groups. An LSR may belong to one or more TE mesh-group(s).
one or more TE meshes.
4. TE mesh-group 3. TE Mesh-Group
4.1. Description 3.1. Description
A TE mesh-group is defined as a group of LSRs that are connected by a A TE mesh-group is defined as a group of LSRs that are connected by a
full mesh of TE LSPs. It is useful to dynamically advertise the full mesh of TE LSPs. Routing extensions are specified in this
desire of a node to join/leave a particular TE mesh-group. This document allowing for dynamic discovery of the TE mesh-group members.
allows for an automatic provisioning of a full mesh of TE LSPs, and Procedures are also specified for a member to join and leave a TE
thus drastically reduces the configuration overhead and risk of mis- mesh-group.
configuration.
4.2. Required Information 3.2. Required Information
This document specifies a TE-MESH-GROUP TLV that indicates the set of This document specifies a TE-MESH-GROUP TLV that indicates the set of
TE mesh-group(s) an LSR belongs to. For each TE mesh group announced TE mesh-group(s) an LSR belongs to. For each TE mesh-group
by the LSR, the TE-MESH-GROUP TLV carries the following information: membership announced by an LSR, the TE-MESH-GROUP TLV advertises the
-A mesh-group number identifying the TE mesh-group, following information:
-A Tail-end address (address used as a tail end address by other
LSRs belonging to the same mesh-group),
-A Tail-end name: string used to ease the TE-LSP naming (e.g.
'head-name->tail-name').
5. TE-MESH-GROUP TLV formats - A mesh-group number identifying the TE mesh-group the LSR belongs
5.1. OSPF TE-MESH-GROUP TLV format to.
The OSPF TE-MESH-GROUP TLV (carried in an OSPF router information LSA - A Tail-end address (used as TE LSP tail-end address by other LSRs
as defined in [OSPF-CAP]) has the following format: belonging to the same mesh-group).
- A Tail-end name: string used to ease the TE-LSP naming.
4. TE-MESH-GROUP TLV formats
4.1. OSPF TE-MESH-GROUP TLV format
the OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information
LSA defined in [I-D.ietf-ospf-cap]) has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | length | | Type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Value // // Value //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OSPF TE-MESH-GROUP TLV format Figure 1 - OSPF TE-MESH-GROUP TLV format
Where Where
Type: identifies the TLV type Type: identifies the TLV type
Length: length of the value field in octets Length: length of the value field in octets
The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV
format used by the Traffic Engineering Extensions to OSPF [OSPF-TE]. format used by the Traffic Engineering Extensions to OSPF
The TLV is padded to four-octet alignment; padding is not included in (see[RFC3630]). The TLV is padded to four-octet alignment; padding
the length field (so a three octet value would have a length of is not included in the length field (so a three octet value would
three, but the total size of the TLV would be eight octets). Nested have a length of three, but the total size of the TLV would be eight
TLVs are also 32-bit aligned. Unrecognized types are ignored. All octets). Nested TLVs are also 32-bit aligned. Unrecognized types
types between 32768 and 65535 are reserved for vendor-specific are ignored. All types between 32768 and 65535 are reserved for
extensions. All other undefined type codes are reserved for future vendor-specific extensions. All other undefined type codes are
assignment by IANA. reserved for future assignment by IANA. The TE-MESH-GROUP TLV is
used to advertise the desire of an LSR to join/leave a given TE mesh-
The TE-MESH-GROUP TLV is used to advertise the desire to group. No sub-TLV is currently defined for the TE-mesh-group TLV.
join/leave a given MPLS TE mesh group. No sub-TLV is currently
defined for the TE-mesh-group TLV.
The TE-MESH-GROUP TLV has the following format: The TE-MESH-GROUP TLV has the following format:
TYPE: To be assigned by IANA (Suggested Value: 3)
LENGTH: Variable
CODE: 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
LENGTH: Variable (N*12 octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name (NULL padded display string) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - TE-MESH-GROUP TLV format (IPv4 Address)
TYPE: To be assigned by IANA (Suggested Value: 4)
LENGTH: Variable
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number | | mesh-group-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end address | | |
| Tail-end IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end name | | Name length | Tail-end name (NULL padded display string) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TE-MESH-GROUP TLV format Figure 3 - TE-MESH-GROUP TLV format (IPv6 Address)
N is the number of mesh-groups.
For each TE mesh group announced by the LSR, the TE-MESH-GROUP TLV For each TE mesh-group announced by the LSR, the TE-MESH-GROUP TLV
contains: comprises:
- A mesh-group-number: identifies the mesh-group number,
- A Tail-end address: user configurable IP address to be used as a
tail-end address by other LSRs belonging to the same mesh-group.
- A Tail-end name: 32-bits string which facilitates the TE LSP
identification which can be very useful in some environments such
as inter-area/AS MPLS TE environments.
5.2. IS-IS TE-MESH-GROUP TLV format - A mesh-group-number that identifies the mesh-group number
The IS-IS TE-MESH-GROUP TLV is composed of 1 octet for the type, 1 - A Tail-end address: an IPv4 or IPv6 IP address to be used as a
octet specifying the TLV length and a value field. tail-end TE LSP address by other LSRs belonging to the same mesh-
group
The format of the TE-MESH-GROUP TLV is identical to the TLV format - A Tail-end name: a variable length field used to facilitate the TE
used by the Traffic Engineering Extensions to IS-IS [IS-IS-TE]. LSP identification. The Name length field indicates the length of
the display string before padding, in bytes.
The TE-MESH-GROUP TLV is used to advertise the desire to join/leave a 4.2. IS-IS TE-MESH-GROUP TLV format
given TE mesh group. No sub-TLV is currently defined for the TE-MESH-
GROUP TLV. The IS-IS TE-MESH-GROUP TLV (advertised in the IS-IS CAPABILITY TLV
defined in [I-D.ietf-isis-caps] ) is composed of 1 octet for the
type, 1 octet specifying the TLV length and a value field. The
format of the TE-MESH-GROUP TLV is identical to the TLV format used
by the Traffic Engineering Extensions for IS-IS [RFC3784]. The TE-
MESH-GROUP TLV is used to advertise the desire of an LSR to join/
leave a given TE mesh-group. No sub-TLV is currently defined for the
TE-MESH-GROUP TLV.
The TE-MESH-GROUP TLV has the following format: The TE-MESH-GROUP TLV has the following format:
TYPE: To be assigned by IANA (Suggested value: 3).
LENGTH: Variable
CODE: 2 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
LENGTH: Variable (N*12 octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name (NULL padded display string) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - TE-MESH-GROUP TLV format (IPv4 Address)
TYPE: To be assigned by IANA (Suggested Value: 4)
LENGTH: Variable
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number | | mesh-group-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end address | | |
| Tail-end IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end name | | Name length | Tail-end name (NULL padded display string) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TE-MESH-GROUP TLV format Figure 5 - TE-MESH-GROUP TLV format (IPv6 Address)
N is the number of mesh-groups. For each TE mesh-group announced by the LSR, the TE-MESH-GROUP TLV
comprises:
For each Mesh-group announced by an LSR, the TLV contains: - A mesh-group-number that identifies the mesh-group number
- A mesh-group-number: identifies the mesh-group number,
- A Tail-end address: user configurable IP address to be used as a
tail-end address by other LSRs belonging to the same mesh-group.
- A Tail-end name: 32-bits string which facilitates the TE LSP
identification which can be very useful in inter-area/AS MPLS TE
environments.
6. Elements of procedure - A Tail-end address: an IPv4 or IPv6 IP address to be used as a
tail-end TE LSP address by other LSRs belonging to the same mesh-
group
- A Tail-end name: a variable length field used to facilitate the TE
LSP identification. The Name length field indicates the length of
the display string before padding, in bytes.
The TE-MESH-GROUP TLV is carried in Link State Advertisements (LSA) 5. Elements of procedure
and Router capability TLV (carried itself within a Link State Packet
(LSP)) for OSPF and ISIS respectively. As such, elements of
procedures are inherited from those defined in [OSPF-CAPS] and [IS-
IS-CAPS]. Specifically, a router MUST originate a new LSA/LSP
whenever the content of this information changes, or whenever
required by regular routing procedure (e.g. refresh).
The TE-MESH-GROUP TLV is OPTIONAL. The TE-MESH-GROUP TLV is carried within the OSPF Routing Information
LSA or ISIS Router capability TLV. As such, elements of procedure
are inherited from those defined in [I-D.ietf-ospf-cap] and
[I-D.ietf-isis-caps] for OSPF and ISIS respectively. Specifically, a
router MUST originate a new LSA/LSP whenever the content of this
information changes, or whenever required by regular routing
procedure (e.g. refresh). The TE-MESH-GROUP TLV is OPTIONAL and must
at most appear once in a OSPF Router Information LSA or ISIS Router
Capability TLV.
6.1. OSPF 5.1. OSPF
The TE-MESH-GROUP TLV is carried within an OSPF router information The TE-MESH-GROUP TLV is advertised within an OSPF Router Information
opaque LSA (opaque type of 4, opaque ID of 0) as defined in [OSPF- opaque LSA (opaque type of 4, opaque ID of 0) as defined in
CAP]. [I-D.ietf-ospf-cap].
A router MUST originate a new OSPF router information LSA whenever A router MUST originate a new OSPF router information LSA whenever
the content of the any of the carried TLV changes or whenever the content of the any of the advertised TLV changes or whenever
required by the regular OSPF procedure (LSA refresh (every required by the regular OSPF procedure (LSA refresh (every
LSRefreshTime)). LSRefreshTime)). If an LSR desires to join or leave a particular TE
mesh group, it MUST originate a new OSPF Router Information LSA
comprising the updated TE-MESH-GROUP TLV. In the case of a join, a
new entry will be added to the TE-MESH-GROUP TLV; conversely, if the
LSR leaves a mesh-group the corresponding entry will be removed from
the TE-MESH-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 TE-MESH-GROUP TLV from a
specific LSR.
As defined in RFC2370, an opaque LSA has a flooding scope determined As defined in [RFC2370], an opaque LSA has a flooding scope
by its LSA type: determined by its LSA type:
- link-local (type 9),
- area-local (type 10)
- entire OSPF routing domain (type 11). In this case, the
flooding scope is equivalent to the Type 5 LSA flooding scope.
A router may generate multiple OSPF router information LSAs with - link-local (type 9);
different flooding scopes.
The TE-MESH-GROUP TLV may be carried within a type 10 or 11 router - area-local (type 10);
information LSA depending on the MPLS TE mesh group profile:
- If the MPLS TE mesh-group is contained within a single area - entire OSPF routing domain (type 11). In this case, the flooding
(all the LSRs have their head-end and tail-end LSR within the scope is equivalent to the Type 5 LSA flooding scope. A router may
same OSPF area), the TE-MESH-GROUP TLV MUST be generated generate multiple OSPF Router Information LSAs with different
within a Type 10 router information LSA, flooding scopes. The TE-MESH-GROUP TLV may be advertised within a
- If the MPLS TE mesh-group spans multiple OSPF areas, the TE type 10 or 11 Router Information LSA depending on the MPLS TE mesh
mesh-group TLV MUST be generated within a Type 11 router group profile:
information LSA,
6.2. IS-IS - If the MPLS TE mesh-group is contained within a single area (all
the LSRs of the mesh-group are contained within a single area), the
TE-MESH-GROUP TLV MUST be generated within a Type 10 Router
Information LSA;
The TE-MESH-GROUP TLV is carried within the IS-IS Router CAPABILITY - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh-
TLV defined in [IS-IS-CAP]. group TLV MUST be generated within a Type 11 router information LSA.
An IS-IS router MUST originate a new IS-IS LSP whenever the content It is expected that the number of mesh-groups and consequently the
of the any of the carried sub-TLV changes or whenever required by the number of TE-MESH-GROUP TLVs advertised within a Routing Information
regular IS-IS procedure (LSP refresh). LSA will be very limited (to at most 10 or so). Moreover, TE mesh-
group membership is fairly static and should not change frequently.
5.2. ISIS
The TE-MESH-GROUP TLV is advertised within the IS-IS Router
CAPABILITY TLV defined in [I-D.ietf-isis-caps]. An IS-IS router MUST
originate a new IS-IS LSP whenever the content of the any of the
advertised sub-TLV changes or whenever required by regular IS-IS
procedure (LSP refresh). If an LSR desires to join or leave a
particular TE mesh group, it MUST originate a new LSP comprising the
refreshed ISIS Router capability TLV comprising the updated TE-MESH-
GROUP TLV. In the case of a join, a new entry will be added to the
TE-MESH-GROUP TLV; conversely, if the LSR leaves a mesh-group the
corresponding entry will be deleted to the TE-MESH-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 TE-MESH-GROUP TLV from a specific LSR.
If the flooding scope of an MPLS Traffic Engineering capability is If the flooding scope of an MPLS Traffic Engineering capability is
limited to an IS-IS level/area, the TLV MUST not be leaked across limited to an IS-IS level/area, the TLV MUST not be leaked across
level/area and the S flag of the Router CAPABILITY TLV MUST be level/area and the S flag of the Router CAPABILITY TLV MUST be
cleared. Conversely, if the flooding scope of an MPLS Traffic cleared. Conversely, if the flooding scope of an MPLS Traffic
Engineering capability is the entire routing domain, the TLV MUST be Engineering capability is the entire routing domain, the TLV MUST be
leaked across levels for IS-IS the S flag of the CAPABILITY TLV MUST leaked across IS-IS levels/areas, and the S flag of the Router
be set. CAPABILITY TLV MUST be set. In both cases the flooding rules
specified in [I-D.ietf-isis-caps] apply.
In both cases the flooding rules as specified in [IS-IS-CAP] apply. As specified in [I-D.ietf-isis-caps], a router may generate multiple
IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different
flooding scopes.
As specified in [IS-IS-CAP], a router may generate multiple IS-IS It is expected that the number of mesh groups and consequently the
CAPABILITY TLVs within an IS-IS LSP with different flooding scopes. number of TE-MESH-GROUP TLV advertised within an ISIS Router
Capability TLV will be very limited (to at most 10 or so). Moreover,
TE mesh-group membership is fairly static and should not change
frequently.
7. Backward compatibility 6. Backward compatibility
The TE-MESH-GROUP TLVs defined in this document do not introduce any The TE-MESH-GROUP TLVs defined in this document do not introduce any
interoperability issue. For OSPF, a router not supporting the TE- interoperability issue. For OSPF, a router not supporting the TE-
MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in
RFC2370. For IS-IS a router not supporting the TE-MESH-GROUP TLV [RFC2370]. For IS-IS a router not supporting the TE-MESH-GROUP TLV
SHOULD just silently ignore the TLV. SHOULD just silently ignore the TLV.
8. Security Considerations 7. IANA Considerations
No new security issues are raised in this document.
9. 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 OSPF
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.
Internet-Drafts are working documents of the Internet Engineering IANA will assign new OSPF TLV code-point for the newly defined TE-
Task Force (IETF), its areas, and its working groups. Note that other MESH-GROUP TLVs carried within the Router Information LSA.
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six TE-MESH-GROUP TLV (IPv4) (suggested value=3)
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".
10. Acknowledgment TE-MESH-GROUP TLV (IPv6) (suggested value=4)
We would like to thank Yannick Le Louedec for his useful comments. ISIS
11. References IANA will assign new ISIS TLV code-point for the newly defined TE-
MESH-GROUP TLVs carried within the ISIS Router Capability TLV.
11.1. Normative references TE-MESH-GROUP TLV (IPv4) (suggested value=3)
[RFC] Bradner, S., "Key words for use in RFCs to indicate TE-MESH-GROUP TLV (IPv6) (suggested value=4)
requirements levels", RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 8. Security Considerations
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF No new security issues are raised in this document.
Technology", BCP 79, RFC 3668, February 2004.
[OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 9. Acknowledgements
[IS-IS] "Intermediate System to Intermediate System Intra-Domain We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec
Routing Exchange Protocol " ISO 10589. and Dave Ward for their useful comments.
[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 10. References
dual environments", RFC 1195, December 1990.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 10.1. Normative References
Extensions to OSPF Version 2", RFC 3630, September 2003.
[IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic [I-D.ietf-isis-caps]
Engineering", RFC 3784, June 2004. Vasseur, J., "IS-IS Extensions for Advertising Router
Information", draft-ietf-isis-caps-06 (work in progress),
January 2006.
[OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, [I-D.ietf-ospf-cap]
J.P., "Extensions to OSPF for advertising Optional Router Lindem, A., "Extensions to OSPF for Advertising Optional
Capabilities", draft-ietf-ospf-cap, work in progress. Router Capabilities", draft-ietf-ospf-cap-08 (work in
progress), December 2005.
[IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
router information", draft-ietf-isis-caps, work in progress. Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998.
[GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp- and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
gmpls-routing-09.txt (work in progress) Tunnels", RFC 3209, December 2001.
[OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
Generalized Multi-protocol Label Switching", draft-ietf-ccamp-ospf- (TE) Extensions to OSPF Version 2", RFC 3630,
gmpls-extensions-12.txt, work in progress. September 2003.
[IS-IS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
Generalized Multi-protocol Label Switching", draft-ietf-isis-gmpls- System (IS-IS) Extensions for Traffic Engineering (TE)",
extensions-19.txt, work in progress. RFC 3784, June 2004.
[INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J. et al, 10.2. Informative References
"Requirements for inter-area MPLS Traffic Engineering", RFC4105, June
2005.
[INT-AS-REQ] Zhang, R., Vasseur, J.P. et al, "MPLS Inter-AS Traffic [OSPF-TE] Katz, et al., RFC 3630, "Traffic Engineering (TE)
Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req, work Extensions to OSPF Version 2", September 2003.
in progress.
[INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A [PCE-DISCO]
Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf- J.L Le Roux, JP Vasseur et al,
ccamp-inter-domain-framework, work in progress. draft-ietf-pce-disco-proto-igp (work in progress)., "IGP
protocol extensions for Path Computation Element (PCE)
Discovery", May .
12. Editors' Address Authors' Addresses
Jean-Philippe Vasseur JP Vasseur (Editor)
Cisco Systems, Inc. Cisco Systems, Inc
300 Beaver Brook Road 1414 Massachusetts Avenue
Boxborough , MA - 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Jean-Louis Le Roux JL Le Roux (Editor)
France Telecom France Telecom
2, avenue Pierre-Marzin 2, Avenue Pierre-Marzin
22307 Lannion Cedex Lanion, 22307
FRANCE FRANCE
Email: jeanlouis.leroux@francetelecom.com Email: jeanlouis.leroux@francetelecom.com
Full Copyright Statement Seisho Yasukawa
NTT
9-11, Midori-Cho 3-Chome
Tokyo, 180-8585
JAPAN
Copyright (C) The Internet Society (2005). Email: yasukawa.seisho@lab.ntt.co.jp
This document is subject to the rights, licenses and restrictions Stefano Previdi
contained in BCP 78, and except as set forth therein, the authors Cisco Systems, Inc
retain all their rights." Via Del Serafico 200
Roma, 00142
Italy
This document and the information contained herein are provided on Email: sprevidi@cisco.com
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE Peter Psenak
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR Cisco Systems, Inc
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF Pegasus Park DE Kleetlaan 6A
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED Diegmen, 1831
BELGIUM
Email: ppsenak@cisco.com
Paul Mabbey
Comcast
USA
Email:
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. 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 99 change blocks. 
320 lines changed or deleted 377 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/