One document matched: draft-vasseur-ccamp-isis-te-caps-00.txt
CCAMP
Internet Draft Jean-Philippe Vasseur
Stefano Previdi
Cisco Systems
Paul Mabey
Qwest
Jean-Louis Le Roux
France Telecom
Document: draft-vasseur-ccamp-isis-te-
caps-00.txt
Expires: August 2004 February 2004
IS-IS MPLS Traffic Engineering capabilities
draft-vasseur-ccamp-isis-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 IS-IS traffic engineering capability sub-TLVs
related to various MPLS Traffic Engineering capabilities. These sub-
TLVs are carried within the IS-IS CAPABILITY TLV.
Conventions used in this document
Vasseur et al. Expires -
- August 2004 [Page 1]
draft-vasseur-ccamp-isis-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
1. Where does this draft fit in the picture of the CCAMP and ISIS WG?
..................................................................2
2. Terminology....................................................2
3. Introduction...................................................3
4. PCED sub-TLV...................................................4
4.1 Description................................................4
4.2 PCED sub-TLV format........................................4
4.2.2 PCE-ADDRESS sub-TLV.........................................4
4.2.3 PCE-CAPABILITY sub-TLV......................................5
4.2.4 AS-DOMAIN sub-TLV...........................................7
5. TE-MESH-GROUP sub-TLV..........................................7
5.1 Introduction...............................................7
5.2 TE-MESH-GROUP sub-TLV format...............................8
6. TE-NODE-CAP sub-TLV............................................9
6.1 Introduction...............................................9
6.2 TE-NODE-CAP sub-TLV format.................................9
7. Element of procedure...........................................9
7.1 PCED sub-TLV..............................................10
7.2 TE-MESH-GROUP sub-TLV.....................................12
7.3 TE-NODE-CAP sub-TLV.......................................12
8. Interoperability with routers non supporting this capability..13
9. Security considerations.......................................13
10. Intellectual Property Considerations.........................13
11. References...................................................14
Normative references.............................................14
Informative references...........................................14
12. Author's Addresses...........................................14
1.
Where does this draft fit in the picture of the CCAMP and ISIS WG?
This document specifies IS-IS extensions in support of MPLS Traffic
Engineering. It will be discussed in the CCAMP Working Group with a
review in the ISIS Working Group.
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
Vasseur et al. Expires -
- August 2004 [Page 2]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
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.
TE LSP head-end: head/source of the TE LSP.
TE LSP tail-end: tail/destination of the TE LSP.
Intra-area TE LSP: TE LSP whose head-end and tail-end reside in the
same area, and whose path does not transit across areas/levels.
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 several IS-IS TE capabilities
sub-TLVs: the PCED (PCE Discovery), the TE-MESH-GROUP and the TE-
NODE-CAP sub-TLVs. These IS-IS TE capability sub-TLVs are carried
within the IS-IS CAPABILITY TLV specified in [IS-IS-CAP].
Each sub-TLV defined in this document is composed of 1 octet for the
type, 1 octet specifying the TLV length and a value field.
The format of each sub-TLV is identical to the TLV format used by the
Traffic Engineering Extensions to IS-IS [IS-IS-TE].
The PCED sub-TLV type is 1. The PCED sub-TLV is made of a set of non-
ordered sub-TLVs each having the format as described above.
The TE-MESH-GROUP sub-TLV type is 2. The TE-MESH-GROUP sub-TLV does
not have any sub-TLV currently defined.
The TE-NODE-CAP sub-TLV type is 3. The TE-NODE-CAP sub-TLV does not
have any sub-TLV currently defined.
Vasseur et al. Expires -
- August 2004 [Page 3]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
4.
PCED sub-TLV
4.1
Description
The PCED sub-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].
The scope of this document is to define a new IS-IS TE capability
sub-TLV carried within an IS-IS CAPABILITY TLV specified in [IS-IS-
CAP] such that a PCE may announce its capability to be a Path
Computation Element within an IS-IS level, 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 dynamic detection of any new
PCE(s), perform some load sharing among a set of potential PCE
candidates or whether that a PCE is no longer active.
4.2
PCED sub-TLV format
This section specifies the sub-TLVs carried within the PCED sub-TLV
payload which define the PCE capabilities.
The PCED sub-TLV is made of various non ordered sub-TLVs defined
bellow:
TLV type Length Name
1 variable PCE-ADDRESS sub-TLV
2 8 PCE-CAPABILITY sub-TLV
3 8 AS-DOMAIN sub-TLV
Any non recognized sub-TLV MUST be silently ignored.
4.2.2 PCE-ADDRESS sub-TLV
The PCE-ADDRESS sub-TLV specifies the IP address to be used to reach
the PCE described by this PCED sub-TLV. This address will typically
be a loop-back address that is always reachable, provided the router
is not isolated. The PCE-ADDRESS sub-TLV is mandatory.
Vasseur et al. Expires -
- August 2004 [Page 4]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
The PCE-ADDRESS sub-TLV type is 1, length is 4 octets for an IPv4
address and 20 octets for an IPv6 address, and the value is the PCE
IPv4 or IPv6 address.
CODE: 1
LENGTH: Variable (4 or 20)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCE IP address //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCE-ADDRESS sub-TLV format
Address-type:
1 IPv4
2 IPv6
The PCE-ADDRESS sub-TLV MUST appear exactly once in the PCED sub-TLV
originated by a router. The only exception is when the PCE has both
an IPv4 and IPv6 address; in this case, two Path Computation Element
address sub-TLVs might be inserted: one for the IPv4 address, one for
the IPv6 address, in this order.
4.2.3 PCE-CAPABILITY sub-TLV
The PCE-CAPABILITY sub-TLV is used by the PCE to signal its Path
Computation Element capabilities. This could then be used by an LSR
to select the appropriate PCE among a list of PCE candidates. This
sub-TLV is optional.
The PCE-CAPABILITY sub-TLV type is 2 and the length is 8 octets.
CODE: 2
LENGTH: 8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|I|A|P|M|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vasseur et al. Expires -
- August 2004 [Page 5]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
PCE-CAPABILITY sub-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/level the ISIS CAPABILITY TLV is flooded into (the
PCE can compute TE LSP paths 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 sub-TLV MUST contain one
or more AS-DOMAIN sub-TLV(s), each describing the domain for which
the PCE 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.
Vasseur et al. Expires -
- August 2004 [Page 6]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
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 sub-TLV to be carried in the PCED capability
sub-TLV if the capability needs more than just a single flag to be
described.
4.2.4 AS-DOMAIN sub-TLV
When the PCE can perform path computation for an inter-AS TE LSP, the
A bit of the PCE-CAPABILITY sub-TLV MUST be set. Moreover, one or
more sub-TLVs MUST be included within the PCED sub-TLV, each sub-TLV
identifying an AS number. Each AS-DOMAIN sub-TLV has the following
form:
CODE: 3
LENGTH: 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AS-DOMAIN sub-TLV format
The AS-DOMAIN sub-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 this document), the AS Number field MUST have its
left two bytes set to 0.
The set of AS-DOMAIN sub-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 sub-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,
Vasseur et al. Expires -
- August 2004 [Page 7]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
(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 sub-TLV (called the TE-MESH-GROUP sub-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 sub-TLV format
The TE-MESH-GROUP sub-TLV has the following format:
CODE: 2
LENGTH: Variable (N*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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TE-MESH-GROUP sub-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.
- A Tail-end name: 32-bits string allowing to ease the TE LSP
identification which can be very useful in inter-area/AS MPLS TE
environments.
Vasseur et al. Expires -
- August 2004 [Page 8]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
6.
TE-NODE-CAP sub-TLV
6.1
Introduction
The aim of the TE-NODE-CAP sub-TLV is to flood some MPLS TE
capabilities that could either be relevant to a single IS-IS level,
area or the entire routing domain.
6.2
TE-NODE-CAP sub-TLV format
The TE-NODE-CAP is a series of bit flags and has a variable length.
CODE: 3
LENGTH: Variable (N*8)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TE-NODE-CAP sub-TLV format
One bit is currently defined:
ªª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]).
Note that some TE capabilities defined in the future may require
inserting a sub-object in the TE-NODE-CAP sub-TLV.
7.
Element of procedure
The sub-TLVs defined in this document are carried within the IS-IS
CAPABILITY TLV defined in [IS-IS-CAP].
An IS-IS router MUST originate a new IS-IS LSP whenever the content
of the any of the carried sub-TLV changes or whenever required by the
regular IS-IS procedure (LSP refresh, + ).
If the flooding scope of an MPLS Traffic Engineering capability is
limited to an IS-IS level/area, the S flag of the CAPABILITY TLV MUST
be cleared.
Vasseur et al. Expires -
- August 2004 [Page 9]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
If the flooding scope of an MPLS Traffic Engineering capability is
the entire routing domain, the S flag of the CAPABILITY TLV MUST be
set.
In both cases the flooding rules as specified in [IS-IS-CAP] apply.
As specified in [IS-IS-CAP], a router may generate multiple IS-IS
CAPABILITY TLVs within an IS-IS LSP with different flooding scopes.
7.1
PCED sub-TLV
If the PCE can compute an intra-area TE LSP path, the L bit of the
PCE-CAPABILITY sub-TLV of the PCED TLV MUST be set. The PCED sub-TLV
MUST be carried:
- Within a CAPABILITY TLV having the S flag cleared if the PCE can
compute an intra-area TE LSP path for the LSRs in the area/level
it resides in
- Within a CAPABILITY TLV having the S flag set if the PCE can
compute an intra-area TE LSP path for the whole domain.
If the PCE can compute an inter-area TE LSP path, the I bit of the
PCE-CAPABILITY sub-TLV of the PCED TLV MUST be set. The PCED sub-TLV
MUST be carried:
- Within a CAPABILITY TLV having the S flag cleared if the PCE can
compute an inter-area TE LSP path for the LSRs in the area(s) it
resides in (for instance the PCE is an ABR computing an inter-area
TE LSP path for its area).
- Within a CAPABILITY TLV having the S flag set 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 sub-TLV of the PCED TLV MUST be set and the PCED TLV MUST
be carried within CAPABILITY TLV having the S flag set.
Note: if the PCE can compute both intra and inter-area TE LSP paths,
both the L and I bits of the PCE-CAPABILITY sub-TLV MUST be set. The
flags are not exclusive.
If the PCE can compute inter-as TE-LSPs path, both the A bit of the
PCED TLV MUST and the S bit of CAPABILITY TLV MUST be set.
Example
<-----------------AS1----------------->
Vasseur et al. Expires -
- August 2004 [Page 10]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
R1(L1)------R3(L1L2)*-----R4(L1L2)*----| ------------
| | | | | |
| S1(L1) | S2(L1) | ASBR1*(L1)--eBGP--ASBR2-| AS2 |
| | | | | |
R2(L1)------R5(L1L2)*-----R6(L1L2)-----| ------------
The areas contents are not detailed.
Assumptions:
- the * indicates a Path computation server capability
- R3 is a PCE for level 1 only
- R5 is a PCE for intra and inter-area TE LSP path computation for
both levels
- R4 is a PCE for inter-area TE LSP path computation only for both
levels
- S1 is a PCE for level 1 only
- S2 is a PCE for the whole AS
- 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 level 1 LSP containing a PCED sub-TLV with:
o The L bit of the PCE-CAPABILITY sub-TLV set,
o The I and A bits of the PCE-CAPABILITY sub-TLV cleared.
The S bit of the CAPABILITY TLV MUST be cleared.
- S2 originates a level 2 LSP containing a PCED TLV with:
o Both the L and I bit of the PCE-CAPABILITY sub-TLV set,
o The A bit of the PCE-CAPABILITY sub-TLV cleared,
The S bit of the CAPABILITY TLV MUST be set
- ASBR1 originates a level1 LSP containing a PCED TLV with:
o The L and I bits of the PCE-CAPABILITY sub-TLV cleared,
o The A bit of the PCE-CAPABILITY sub-TLV set,
o One AS-domain sub-TLV within the PCED sub-TLV with AS number =
AS2
The S bit of the CAPABILITY TLV MUST be set
- R3 originates:
* a level 1 LSP containing
- an IS-IS CAPABILITY TLV with the S flag cleared carrying:
o a PCED TLV describing its own PCE capability with:
- The L bit of the PCE-CAPABILITY sub-TLV set,
- The I and A bits of the PCE-CAPABILITY sub-TLV
cleared,
- an IS-IS CAPABILITY TLV with the S flag set carrying:
o the S2ªs PCED TLV (with I and A bit unchanged)
Vasseur et al. Expires -
- August 2004 [Page 11]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
o the ASBR1ªs PCED TLV (unchanged), leaked from level-2 LSP (S
bit set).
* a level 2 LSP including no PCED TLV
- R5 originates:
* a level1 LSP containing:
- an IS-IS CAPABILITY TLV with the S flag cleared carrying:
o a PCED TLV describing its own PCE capability with:
- The L and I bits of the PCE-CAPABILITY sub-TLV set,
- The A bit of the PCE-CAPABILITY sub-TLV cleared,
- an IS-IS CAPABILITY TLV with the S flag set carrying:
o the S2ªs PCED TLV (with the I, A and L bits of the PCE-
CAPABILITY sub-TLV unchanged)
o the ASBR1ªs PCED TLV (unchanged)
* a level 2 LSP containing an IS-IS CAPABILITY TLV with the S flag
cleared carrying:
o a PCED sub-TLV describing its own PCED capability with:
- Both the L and I bit of the PCE-CAPABILITY sub-TLV set,
- The A bit of the PCE-CAPABILITY sub-TLV cleared.
The receipt of an IS-IS LSP containing a new PCED TLV never triggers
an SPF calculation.
When a PCE is newly configured, the corresponding PCED TLV MUST be
immediately flooded.
When a PCE looses its capability or when one of its PCED capabilities
changes, the IS-IS LSP MUST be immediately flooded.
7.2
TE-MESH-GROUP sub-TLV
If the MPLS TE mesh-group is contained within a single IS-IS
level/area (all the LSRs have their head-end and tail-end LSR within
the same IS-IS level/area), the TE-MESH-GROUP sub-TLV MUST be carried
within a CAPABILITY TLV having the S flag cleared.
If the MPLS TE mesh-group spans multiple IS-IS levels/areas, the TE-
MESH-GROUP sub-TLV MUST be carried within a CAPABILITY TLV having the
S flag set.
7.3
TE-NODE-CAP sub-TLV
The flooding scope is defined on a per capability basis.
Vasseur et al. Expires -
- August 2004 [Page 12]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
If the capability must be flooded within a single IS-IS area/level,
the TE-NODE-CAP sub-TLV MUST be carried within a CAPABILITY TLV
having the S flag cleared.
If the capability must be flooded throughout the entire routing
domain, the TE-NODE-CAP sub-TLV MUST be carried within a CAPABILITY
TLV having the S flag set.
Capabilities with an identical flooding scope MUST be flooded within
the same TE-NODE-CAP sub-TLV.
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 sub-TLVs SHOULD just silently
ignore those sub-TLVs.
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
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.
Vasseur et al. Expires -
- August 2004 [Page 13]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
11.
References
Normative references
[RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119.
[IS-IS] "Intermediate System to Intermediate System Intra-Domain
Routeing Exchange Protocol for use in Conjunction with the Protocol
for Providing the Connectionless-mode Network Service (ISO 8473)",
ISO 10589.
[IS-IS-IP] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in
TCP/IP and dual environments", RFC 1195, December 1990.
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-04.txt (work in progress)
[IS-IS-CAP] Vasseur JP, Previdi S. Shand M.,Ginsberg L. "IS-IS
extensions for advertising router capabilities", <draft-vasseur-isis-
caps-01.txt>, Internet Draft, work in progress.
Informative references
[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.
[P2MP-reqs] S. Yasukawa et al. + Requirements for point to multipoint
extension to RSVP -, draft-ietf-mpls-p2mp-requirement-01.txt, work in
progress.
12.
Author's Addresses
Jean-Philippe Vasseur
CISCO Systems, Inc.
300 Beaver Brook
Boxborough, MA 01719
USA
Email: jpv@cisco.com
Stefano Previdi
Vasseur et al. Expires -
- August 2004 [Page 14]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
CISCO Systems, Inc.
Via Del Serafico 200
00142 - Roma
ITALY
Email: sprevidi@cisco.com
Paul Mabey
Qwest Communications
950 17th Street,
Denver, CO 80202
USA
Email: pmabey@qwest.com
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
E-mail: jeanlouis.leroux@francetelecom.com
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.
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
Vasseur et al. Expires -
- August 2004 [Page 15]
draft-vasseur-ccamp-isis-te-caps-00.txt February 2004
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] | PAFTECH AB 2003-2026 | 2026-04-22 23:32:53 |