CCAMP
Internet Draft Jean-Philippe Vasseur
Peter Psenak
Cisco Systems
Seisho Yasukawa
NTT
Document: draft-vasseur-ccamp-ospf-te-
caps-00.txt
Expires: August 2004 February 2004
OSPF MPLS Traffic Engineering capabilities
draft-vasseur-ccamp-ospf-te-caps-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].
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
This document proposes OSPF traffic engineering capability TLVs and
is composed of several sub-TLVs related to various MPLS Traffic
Engineering capabilities. These OSPF TE capability TLVs are carried
within the OSPF router information LSA (opaque type of 4, opaque ID
of 0).
Conventions used in this document
Vasseur et al. Expires û August 2004 [Page 1]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
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 [ii].
Table of Contents
0. Background.....................................................2
1. Where does this draft fit in the picture of the CCAMP and OSPF WG?
..................................................................2
2. Terminology....................................................3
3. Introduction...................................................3
4. PCED TE TLV....................................................4
4.1 Description................................................4
4.2 PCED TLV format............................................5
4.2.2 PCE-ADDRESS TLV.............................................5
4.2.3 PCE-CAPABILITY TLV..........................................6
4.2.4 AS-DOMAIN TLV...............................................7
5. TE-MESH-GROUP TLV..............................................8
5.1 Introduction...............................................8
5.2 TE-MESH-GROUP TLV format...................................8
6. TE-NODE-CAP TLV................................................9
6.1 Introduction...............................................9
6.2 TE-NODE-CAP TLV format.....................................9
7. Element of procedure..........................................10
7.1 PCED TLV..................................................10
7.2 TE-MESH-GROUP TLV.........................................12
7.3 TE-NODE-CAP TLV...........................................13
8. Interoperability with routers non supporting this capability..13
9. Security considerations.......................................13
10. Intellectual Property Considerations.........................13
11. Acknowledgments..............................................14
12. References...................................................14
Normative references.............................................14
Informative references...........................................14
13. Author's Addresses...........................................15
0. Background
This draft is the next revision of the former draft draft-vasseur-
mpls-ospf-te-cap-00.txt.
1.
Where does this draft fit in the picture of the CCAMP and OSPF WG?
This document specifies OSPF extensions in support of MPLS Traffic
Engineering. It will be discussed in the CCAMP Working Group with a
review in the OSPF Working Group.
Vasseur et al. Expires û August 2004 [Page 2]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
2.
Terminology
Terminology used in this document
LSR: Label Switch Router.
PCE: Path Computation Element whose function is to compute the path
of a TE LSP it is not the head-end for. The PCE may be an LSR (e.g
ABR or ASBR) in the context of some distributed PCE-based path
computation scenario as defined in [INTER-AREA-AS] or a centralized
Path Computation Element not forwarding packet.
PCC: Path Computation Client (any head-end LSR) requesting a TE LSP
path computation to the Path Computation Element.
TE LSP: Traffic Engineering Label Switched Path.
Head-end TE LSP: head/source of the TE LSP.
Tail-end TE LSP: tail/destination of the TE LSP.
Intra-area TE LSP: TE LSP whose head-end and tail-end reside in the
same area.
Inter-area MPLS TE LSP: A TE LSP where the head-end LSR and tail-end
LSR do not reside in the same area or both the head-end and tail end
LSR reside in the same area but the TE LSP transits one or more
different areas along the path.
Inter-AS MPLS TE LSP: A TE LSP whose head-end LSR and tail-end LSR do
not reside within the same Autonomous System (AS), or whose head-end
LSR and tail-end LSR are both in the same AS but the TE LSPÆs path
may be across different ASes. Note that this definition also applies
to TE LSP whose Head-end and Tail-end LSRs reside in different sub-
ASes (BGP confederations).
3.
Introduction
This document describes the usage of three OSPF TE capabilities TLVs:
the PCED (PCE Discovery) TLV, the TE-MESH-GROUP and the TE-NODE-CAP
TLVs. These OSPF TE capability TLVs are carried within the OSPF
router information LSA (opaque type of 4, opaque ID of 0) specified
in [OSPF-CAP].
Each TE TLV defined in this document and carried in an OSFP router
information LSA as defined in [OSPF-CAP] has the following format:
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
Vasseur et al. Expires û August 2004 [Page 3]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where
Type: identifies the TLV type
Length: length of the value field in octets
The format of the TLV is the same as the TLV format used by the
Traffic Engineering Extensions to OSPF [OSPF-TE]. 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). Nested TLVs are also 32-bit
aligned. Unrecognized types are ignored. All types between 32768
and 65535 are reserved for vendor-specific extensions. All other
undefined type codes are reserved for future assignment by IANA.
Note that a sub-TLV is similar to a TLV: TLV are carried within an
LSA as sub-TLVs are carried within TLVs. Each sub-TLV describes a
particular MPLS Traffic Engineering capability. In the rest of this
document both terms will be used interchangeably.
The PCED TLV type is 1. The PCED TLV is made of a set of non-ordered
TLVs each having the format as described above.
The TE-MESH-GROUP TLV type is 2. The TE-MESH-GROUP TLV does not have
any sub-TLV currently defined.
The TE-NODE-CAP TLV type is 3. The TE-NODE-CAP TLV does not have any
sub-TLV currently defined.
4.
PCED TE TLV
4.1
Description
The PCED TLV allows for the auto-discovery of one or more Path
Computation Element(s). In various situations (GMPLS, inter-area TE,
inter-AS TE, etc), an LSR maybe required to send a request to a Path
Computation Element (PCE) to compute one or more TE LSP paths obeying
a set of specified constraints ([INTER-AREA-AS]). An example of such
a signaling protocol used between a PCC to send a request to a PCE
and conversely a PCE to return a reply to a PCC is defined in [PATH-
COMP].
Vasseur et al. Expires û August 2004 [Page 4]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
The scope of this document is to define a new OSPF TE capability TLV
carried within an OSPF router information LSA such that a PCE may
announce its capability to be a Path Computation Element within an
OSPF area or an Autonomous System. This allows every LSR in the
network to automatically discover the Path Computation Element(s) and
recognize its capability(ies), which substantially simplifies head-
end LSRs configuration. Moreover, this allows detecting dynamically
any new PCE(s), performs some load sharing among a set of potential
PCE candidates or that a PCE is no longer active.
4.2
PCED TLV format
This section specifies the sub-TLVs carried within the PCED TLV
payload which define the PCE capabilities.
The PCED TLV is made of various non ordered sub-TLVs defined bellow:
TLV type Length Name
1 variable PCE-ADDRESS TLV
2 8 PCE-CAPABILITY TLV
3 8 AS-DOMAIN TLV
Any non recognized TLV MUST be silently ignored.
4.2.2 PCE-ADDRESS TLV
The PCE-ADDRESS TLV specifies the IP address to be used to reach the
PCE described by this PCED TLV. This address will typically be a
loop-back address that is always reachable, provided the router is
not isolated. The PCE-ADDRESS TLV is mandatory.
The PCE address TLV type is 1, length is 8 octets for an IPv4 address
and 20 octets for an IPv6 address, and the value is the PCE IPv4 or
IPv6 address.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | variable (8 or 20) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCE IP address //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCE-ADDRESS TLV format
Vasseur et al. Expires û August 2004 [Page 5]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
Address-type:
1 IPv4
2 IPv6
The PCE-ADDRESS TLV MUST appear exactly once in the PCED TLV
originated by a router. The only exception is when the PCE has both
an IPv4 and IPv6 address; in this case, two PCE-ADDRESS TLVs might be
inserted: one for the IPv4 address, one for the IPv6 address, in this
order.
4.2.3 PCE-CAPABILITY TLV
The PCE-CAPABILITY TLV is used by the PCE to signal its Path
Computation Element capabilities. This could be used by an LSR to
select the appropriate PCE among a list of PCE candidates. This TLV
is optional.
The PCE-CAPABILITY TLV type is 3 and the length is 8 octets.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|I|A|P|M|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCE-CAPABILITY TLV format
The first 3 bits L, I and A defines the PCEÆs scope for which the
Path Computation Element is capable of performing the TE LSP path
computation.
L bit
Local scope. When set, this flag indicates that the PCE can compute
paths for the area the LSA is flooded into (the PCE can compute TE
LSP path for intra-area TE LSPs).
I bit
Inter-area scope. When set, the PCE can perform TE LSP path
computation for inter-area TE LSPs but within the same AS.
A bit
Multi-domain scope. When set, the PCE can perform path computation
for inter-AS TE LSPs. In this case, the PCED TLV MUST contain one or
more AS-DOMAIN TLV(s), each describing the domain for which the PCE
Vasseur et al. Expires û August 2004 [Page 6]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
can compute TE LSPs paths having their destination address in the
respective AS.
Note that those flags are not exclusive (a PCE may set one or more
flags).
P bit
The notion of request priority allows a PCC to specify how urgent the
request is, by setting a flag in the REQUEST_ID object of the Path
computation request message. See [PATH-COMP] for more details.
P=1: the PCE takes into account the ôrequest priorityö in its
scheduling of the various requests.
P=0: the PCE does not take the request priority into account.
M bit
M=1: the PCE is capable of computing more than one path obeying a set
of specified constraints (in a single pass), provided that they
exist.
M=0: the PCE cannot compute more than one path in a single pass
obeying a set of specified constraints.
D bit
The PCC may request the PCE to compute N diversely routed paths
obeying a set of specified constraints. Such N paths may not exist of
course depending on the current state of the network. See [PATH-COMP]
for more details.
D=1: the PCE is capable of computing diversely (link, node, SRLG)
routed paths.
D=0: the PCE is not capable of computing diversely routed paths.
The D bit is relevant if and only if the M bit has been set to 1. It
MUST be set to 0 if the M bit is set to 0.
Note that for future capabilities, it may be desirable to introduce
new flags or may be new TLV to be carried in the PCED capability TLV
if the capability needs more than just a single flag to be described.
4.2.4 AS-DOMAIN TLV
When the PCE can perform path computation for an inter-AS TE LSP, the
A bit of the PCE-CAPABILITY TLV MUST be set. Moreover, one or more
TLVs MUST be included within the PCED TLV, each TLV identifying an AS
number. Each AS-DOMAIN TLV has the following form:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vasseur et al. Expires û August 2004 [Page 7]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
| AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AS-DOMAIN TLV format
The AS-DOMAIN TLV type is 3, length is 4 octets, and the value is the
AS number identifying the AS for which the PCE can compute inter-AS
TE LSP paths (TE LSP having their destination address in this AS).
When coded on two bytes (which is the current defined format as the
time of writing), the AS Number field MUST have its left two bytes
set to 0.
The set of AS-DOMAIN TLVs specifies a list of ASes (AS1, à , ASn).
This means that the PCE can compute TE LSP path such that the
destination address of the TE LSP belongs to this set of ASes.
5.
TE-MESH-GROUP TLV
5.1
Introduction
As of today, there are different approaches in deploying MPLS Traffic
Engineering:
(1) The ôsystematic approach consisting of setting up a full
mesh of TE LSPs between a set of LSRs,
(2) The "by exception" approach where a set of TE LSPs are set
up on hot spots to alleviate a congestion resulting for instance
in an unexpected traffic growth in some part of the network.
Setting up a full mesh of TE LSPs between a set of LSRs requires the
configuration of a large number of TE LSPs on every head-end LSR. A
full TE mesh of n LSRs requires to set up O(n^2) TE LSPs.
Furthermore, the addition of any new LSR in the mesh implies to
configure n TE LSPs on the new LSR and to add a new TE LSP on every
LSR ending to this new LSR, which gives a total of 2*n TE LSPs. This
is not only time consuming but also not a low risk operation for
Service Providers. Hence, a more automatic way of setting up a full
mesh of TE LSPs is desirable. This requires defining a new TE
capability TLV (called the TE-MESH-GROUP TLV) such that an LSR can
announce its desire to join a particular TE LSP mesh, identified by a
mesh-group number.
5.2
TE-MESH-GROUP TLV format
The TE-MESH-GROUP TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |Length: Variable (N*8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vasseur et al. Expires û August 2004 [Page 8]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
| mesh-group-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TE-MESH-GROUP TLV format
N is the number of mesh-groups.
For each Mesh-group announced by the LSR, the TLV contains:
- 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.
6.
TE-NODE-CAP TLV
6.1
Introduction
The aim of the TE-NODE-CAP TLV is to flood some MPLS TE related
capabilities that could either be relevant to a single area and in
this case it will be carried within a type 10 router information LSA
or the entire routing domain and will be carried within type 11
router information LSA.
6.2
TE-NODE-CAP TLV format
The TE-NODE-CAP is a series of bit flags and has a variable length.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |Length: Variable (N*8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TE-NODE-CAP TLV format
One bit is currently defined:
0x01: ôBö bit. When set, this indicates that the LSR has the capability
to act as a branch node for an MPLS Point to Multipoint TE LSP (see
[P2MP-reqs] and [P2MP]).
Vasseur et al. Expires û August 2004 [Page 9]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
Note that some TE capabilities defined in the future may require
inserting a sub-object in the TE-NODE-CAP TLV.
7.
Element of procedure
The TLVs defined in this document are carried within an OSPF router
information opaque LSA (opaque type of 4, opaque ID of 0) as defined
in [OSPF-CAP].
A router MUST originate a new OSPF router information LSA whenever
the content of the any of the carried TLV changes or whenever
required by the regular OSPF procedure (LSA refresh (every
LSRefreshTime, à)).
As defined in RFC2370, an opaque LSA has a flooding scope 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
different flooding scopes.
7.1
PCED TLV
The PCED TLV may be carried within a type 10 or 11 router information
LSA depending on the Path Computation Element scope.
- If the PCE can compute an intra-area TE LSP, the L bit of the
PCE-CAPABILITY TLV of the PCED TLV MUST be set and the PCED TLV
MUST be generated within a Type 10 router information LSA,
- If the PCE can compute an inter-area TE LSP, the I bit of the
PCE-CAPABILITY TLV of the PCED TLV MUST be set. The PCED TLV
MUST be generated:
- within a Type 10 router information LSA if the PCE can
compute an inter-area TE LSP path for the LSRs in the
area it is attached to (for instance the PCE is an ABR
computing an inter-area TE LSP path for its attached
areas)
- within a Type 11 router information LSA if the PCE can
compute an inter-area TE LSP path for the whole domain.
- If the PCE can compute an inter-AS TE LSP path, the A bit of
the PCE-CAPABILITY TLV of the PCED TLV MUST be set and the PCED
TLV MUST be generated within a Type 11 router information LSA,
Vasseur et al. Expires û August 2004 [Page 10]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
Note: if the PCE can compute both intra and inter-area TE LSP paths,
both the L and I bits of the PCE-CAPABILITY TLV MUST be set. The
flags are not exclusive. This only applies to the PCED TLV carried
within the type 10 router information LSA.
If a PCE can compute an intra-area TE LSP and an inter-area or inter-
AS TE LSP path, it MUST originate:
- a type 10 OSPF router information LSA with a PCED TLV having
L=1 and the I and A flags of its PCE-CAPABILITY TLV set as
described above,
- a type 11 OSPF router information LSA with a PCED TLV having
L=0 and the I and A flags of its PCE-CAPABILITY TLV set as
described above,
Example
<-----------------AS1----------------->
<---area 1--><----area 0-----><-area 2->
R1---------ABR1*------------ABR3*-----| ------------
| | | | | |
| S1 | S2 | ASBR1*--eBGP--ASBR2-| AS2 |
| | | | | |
R2---------ABR2*------------ABR4------| ------------
The areas contents are not detailed.
Assumptions:
- area 1 and area 2 are regular areas
- the * indicates a Path Computation Element capability
- ABR1 is a PCE for area 1 only
- ABR2 is a PCE for intra and inter-area TE LSP path computation in
area 0 and 1
- ABR3 is a PCE for only inter-area TE LSP path computation for the
whole domain,
- S1 is a PCE for area 1 only
- S2 is a PCE for the whole domain,
- ASBR1 is a PCE for inter-AS TE LSPs whose destination resides in
AS2 (not for intra or inter-area area TE LSPs).
In the example above:
- S1 originates a type 10 router information LSA with a PCED TLV such
that:
o The L bit of the PCE-CAPABILITY TLV is set,
o The I and A bits of the PCE-CAPABILITY TLV are cleared.
Vasseur et al. Expires û August 2004 [Page 11]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
- ABR1 originates in area 1 a type 10 router information LSA with a
PCED TLV such that:
o The L bit of the PCE-CAPABILITY TLV is set,
o The I and A bits of the PCE-CAPABILITY sub-TLV are cleared,
- ABR2 originates in both area 0 and 1 a type 10 router information
LSA with a PCED TLV such that:
o The L and I bits of the PCE-CAPABILITY TLV are set,
o The A bit of the PCE-CAPABILITY TLV is cleared
- ABR3 originates a type 11 router information LSA with a PCED TLV
such that:
o The L bit of the PCE-CAPABILITY TLV is cleared,
o The I bit of the PCE-CAPABILITY TLV is set,
o The A bit of the PCE-CAPABILITY TLV is cleared,
- S2 originates:
- in area 0 a type 10 router information LSA with a PCED TLV
such that:
o The L and I bits of the PCE-CAPABILITY sub-TLV are
set,
o The A bit of the PCE-CAPABILITY TLV is cleared,
- a type 11 router information LSA with a PCED TLV such that:
o The L bit of the PCE-CAPABILITY TLV is cleared,
o The I bit of the PCE-CAPABILITY TLV is set,
o The A bit of the PCE-CAPABILITY TLV is cleared,
- ASBR1 originates a type 11 router information LSA with a PCED TLV
such that:
o The L bit and the I bit of the PCE-CAPABILITY TLV are cleared,
o The A bit of the PCE-CAPABILITY TLV set,
o One AS-DOMAIN TLV within the PCED TLV with AS number = AS2
The receipt of a new router information LSA carrying a PCED TLV never
triggers an SPF calculation.
When an LSR or a Path Computation Element is newly configured as a
PCE, the corresponding router information LSA MUST be immediately
flooded.
When a PCE capability changes, the corresponding router information
LSA MUST be immediately flooded.
When a PCE looses its Path Computation Element capability, the
corresponding router information LSA MUST be immediately flooded with
LS age = MaxAge.
7.2
TE-MESH-GROUP TLV
Vasseur et al. Expires û August 2004 [Page 12]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
The TE-MESH-GROUP TLV may be carried within a type 10 or 11 router
information LSA depending on the MPLS TE mesh-group profile:
- If the MPLS TE mesh-group is contained within a single area
(all the LSRs have their head-end and tail-end LSR within the
same OSPF area), the TE-MESH-GROUP TLV MUST be generated within
a Type 10 router information LSA,
- If the MPLS TE mesh-group spans multiple OSPF areas, the TE-
MESH-GROUP TLV MUST be generated within a Type 11 router
information LSA,
7.3
TE-NODE-CAP TLV
The TE-NODE-CAP may be carried within a type 10 or 11 router information
LSA depending on the MPLS Traffic Engineering capability. The flooding
scope is defined on a per capability basis. Capabilities with a
identical flooding scope MUST be flooded within the same TE-NODE-CAP TLV
carried within a router information LSA.
8.
Interoperability with routers non supporting this capability
There is no interoperability issue as a router not supporting the
PCED, TE-MESH-GROUP or TE-NODE-CAP TLVs SHOULD just silently discard
those TLVs as specified in RFC2370.
9.
Security considerations
No new security issues are raised in this document.
10.
Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
Vasseur et al. Expires û August 2004 [Page 13]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
11.
Acknowledgments
The authors would like to thank Abhay Roy, Dan Tappan, Robert Raszuk
and Vishwas Manral for their comments.
12.
References
Normative references
[RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119.
[OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPF-OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370,
July 1998.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", RFC 3630.
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-04.txt (work in progress)
Informative references
[OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S.,
Vasseur, JP., "Extensions to OSPF for Advertising Optional Router
Capabilities", <draft-ietf-ospf-cap-00.txt>, Internet Draft, work in
progress.
[INTER-AREA-AS] Vasseur and Ayyangar, ôInter-area and Inter-AS MPLS
Traffic Engineeringö, draft-vasseur-ayyangar-inter-area-AS-TE-00.txt,
work in progress.
[PATH-COMP] Vasseur et al, ½RSVP Path computation request and reply
messages ©, draft-vasseur-mpls-computation-rsvp-te-03.txt, work in
progress.
[P2MP] S. Yasukawa et al. ½ Extended RSVP TE for point-to-multipoint
LSP tunnelsö, draft-yasukawa-mpls-rsvp-p2mp-03.txt, work in progress.
Vasseur et al. Expires û August 2004 [Page 14]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
[P2MP-reqs] S. Yasukawa et al. ½ Requirements for point to multipoint
extension to RSVP ©, draft-ietf-mpls-p2mp-requirement-01.txt, work in
progress.
13.
Author's Addresses
Jean-Philippe Vasseur
CISCO Systems, Inc.
300 Beaver Brook
Boxborough, MA 01719
USA
Email: jpv@cisco.com
Peter Psenak
CISCO Systems, Inc.
Pegasus Parc
De Kleetlaan 6A
1831, Diegem
BELGIUM
Email: ppsenak@cisco.com
Seisho Yasukawa
NTT Network Service Systems Laboratories, NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: + 81 422 59 4769
Email: yasukawa.seisho@lab.ntt.co.jp
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
Vasseur et al. Expires û August 2004 [Page 15]
draft-vasseur-ccamp-ospf-te-caps-00.txt February 2004
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS 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.
Vasseur et al. Expires û August 2004 [Page 16]