[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-vasseur-mpls-isis-pcsd-discovery-00.txt
Hi,
NAME OF I-D:
IS-IS Path Computation Server discovery TLV
SUMMARY
This draft proposes an IS-IS extension for a router to announce its
Path Computation Server capability used in the context of MPLS
Traffic Engineering. This draft defines a new TLV called PCSD sub-
TLV (Path Computation Server Discovery) which is carried within the
IS-IS LSP.
RELATED DOCUMENTS:
None
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK:
This document specifies IS-IS extensions in support of MPLS Traffic
Engineering. It relates to the work on the off-load computation of
Traffic Engineering Label Switch Path covered by CCAMP.
This document fits into CCAMP WG.
WHY IS IT TARGETED AT THIS WG
This addresses specific items of the CCAMP WG charter.
From the CCAMP WG Charter:
"- Define signalling protocols and measurement protocols such that they
support multiple physical path and tunnel technologies (e.g. O-O and O-E-O
optical switches, ATM and Frame Relay switches, MPLS, GRE) using input from
technology-specific working groups such as MPLS, IPO, etc.
- Define signalling and measurement protocols that are independent of each
other. This allows applications other than the signalling protocol to use
the measurement protocol; it also allows the signalling protocol to use
knowledge obtained by means other than the measurement protocol.
..."
JUSTIFICATION
The draft directly addresses items of the charter.
Many thanks in advance.
Best regards.
JP.
Internet draft draft-vasseur-mpls-isis-pcsd-discovery-00.tx June 2002
Network Working Group JP Vasseur
Internet Draft Cisco Systems, Inc
Document: draft-vasseur-mpls-isis-pcsd-discovery-00.txt
IETF Internet Draft
Expires: December, 2002
June 2002
IS-IS Path Computation Server discovery TLV
draft-vasseur-mpls-pcsd-isis-discovery-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. 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 draft proposes an IS-IS extension for a router to announce its
Path Computation Server capability used in the context of MPLS
Traffic Engineering. This draft defines a new TLV called PCSD sub-
TLV (Path Computation Server Discovery) which is carried within the
IS-IS LSP.
1. Where does this draft fit in the picture of the Sub-IP work
This document specifies IS-IS extensions in support of MPLS Traffic
Engineering. It relates to the work on the off-load computation of
Traffic Engineering Label Switch Path covered by CCAMP.
Vasseur 1
Internet draft draft-vasseur-mpls-pcsd-discovery-00.txt June 2002
2. Terminology
Terminology used in this draft
LSR: Label Switch Router
PCS: Path Computation Server (may be an LSR (ABR, ASBR, ...) or a
dedicated path computation server (typically a UNIX machine) not
forwarding packet.
PCC: Path Computation Client (any head-end LSR) requesting a path
computation to the Path Computation Server.
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 TE LSP: TE LSP whose head-end and tail-end reside in
different areas (the TE LSP spans areas)
Inter-AS TE LSP: TE LSP whose head-end and tail-end reside in
different Autonomous Systems (the TE LSP spans AS)
3. Introduction
This draft specifies an IS-IS PCSD TLV, carried within an IS-IS LSP
for the Auto-discovery of one or more Path Computation Server(s).
In various situations, an LSR may send a request to a Path
Computation Server (PCS) to compute one or more Traffic Engineering
LSP paths obeying a set of specified constraints.
[13] specifies RSVP extensions:
- for a PCC to send path computation requests to a PCS to
compute TE LSP(s) obeying a set of specified constraints,
- for the PCS to provide to the PCC one or more computed paths
obeying the set of constraints (or to return an indication
mentioning no path obeying the constraints could be found).
The scope of this document is to define an IS-IS TLV such that an
LSR/centralized path computation tool may announce its capability to
be a Path Computation Server within an area or an Autonomous System.
This allows every LSR in the network to automatically discover the
Path Computation Server(s), which substantially simplifies the head-
Vasseur 2
Internet draft draft-vasseur-mpls-pcsd-discovery-00.txt June 2002
end LSR configuration. Moreover, this allows to detect dynamically
any new PCS or that a PCS is no longer active.
4. PCSD (Path Computation Server Discovery) TLV format
This section defines the PCSD TLV carried within the IS-IS LSP
payload.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCSD TLV format
Type: identifies the TLV type - TBD by the IS-IS WG (see [22])
Length: variable
Value: the PCSD TLV is itself made of various non ordered sub-TLVs
defined bellow:
Sub-TLV type Length Name
1 4 Path computation server scope sub-TLV
2 variable Path computation server address sub-TLV
3 8 Path computation server capability sub-TLV
4 8 AS-domain sub-TLV
Any non recognized sub-TLV MUST be silently ignored.
4.1 Path computation server scope sub-TLV
The path computation server scope sub-TLV specifies the zone for
which the path computation server is capable of performing TE LSP
path computation.
The path computation server scope sub-TLV type is 1, its length is 4,
and the value is a set of flags:
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 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | |A|I|L|
Vasseur 3
Internet draft draft-vasseur-mpls-pcsd-discovery-00.txt June 2002
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path computation server scope sub-TLV format
Flags: no flags are currently defined.
Scope
L (local scope). When set, this flag indicates that the PCS can
compute paths for the level the LSP is flooded into (i.e the PCS can
compute TE LSP path for intra-area TE LSPs).
I (inter-area scope). When set, the PCS can perform TE LSP path
computation for inter-area TE LSPs (i.e TE LSP whose destination IP
address belongs to another area of the head-end LSR) but within the
same AS.
A (multi-domain scope). When set, the PCS can perform path
computation for inter-domain TE LSP. In this case, the PCSD TLV MUST
contain one or more AS-domain sub-TLV(s) each describing the domain
for which the PCS can compute TE LSPs paths having their destination
address in this domain.
Note that a PCS MAY set one or more flags.
See section 4 for a detailed description of the elements of
procedure.
4.2 Path Computation Server address sub-TLV
The PCS address sub-TLV specifies the IP address to be used to reach
the PCS described by this PCSD TLV. This address will typically be a
loop-back address, always reachable, provided the router is not
isolated. This sub-TLV is required.
The PCS address sub-TLV type is 2, length is 4 octets for an IPv4
address and 16 octets for an IPv6 address, and the value is the PCS
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | variable (4 or 16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCS IP address //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vasseur 4
Internet draft draft-vasseur-mpls-pcsd-discovery-00.txt June 2002
Path Computation Server address sub-TLV format
Address-type:
1 IPv4
2 IPv6
The router address sub-TLV MUST appear exactly once in the PCSD sub-
TLV originated by a router.
4.3 Path Computation Server capability sub-TLV
The PCS capability sub-TLV is used by the PCS to signal its path
computation server capabilities. This sub-TLV is optional.
The PCS capability sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|M|D|E|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCS capability sub-TLV format
P bit
The notion of request priority allows a PCC to specify how urgent is
the request setting a flag in the REQUEST_ID object of the Path
computation request message. See [13] for more details.
P=1: the PCS takes into account the "request priority" in its
scheduling of the various requests.
P=0: the PCS does not take the request priority into account
M bit
M=1: the PCS is capable of computing more than one paths obeying a
set of specified constraints, provided that they exist.
M=0: the PCS cannot compute more than one path obeying a set of
specified constraints.
D bit
The PCC MAY request the PCS 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 [13] for more details.
D=1: the PCS is capable of computing diversely (link, node, SRLG)
routed paths.
D=0: the PCS is not capable of computing diversely routed paths.
Vasseur 5
Internet draft draft-vasseur-mpls-pcsd-discovery-00.txt June 2002
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.
E bit
The PCC may request the PCS the computation of a path obeying a set
of constraints one of those constraints being that one or more
specified network element object must not be traversed by the LSP (a
network element may be a link, an LSR or an Autonomous System). See
[13] for more details.
E=1: the PCS is capable of computing TE LSP paths excluding some
network elements.
E=0: the PCS is not capable of computing paths excluding network
elements.
G bit
As defined in [13], the PCC may send a request specifying the metric
to be used by the PCS when computing the shortest path during the
CSPF.
G=1: the PCS supports the computation of CSPF with various metrics
G=0: the PCS just computes the CSPF based on the TE metric
Note that for future capability, it MAY be desirable to introduce
new flags or may be new sub-TLV to be carried in the PCSD TLV if the
capability needs more than just a single flag to be described.
4.4 AS-domain sub-TLV
When the PCS can perform path computation for inter-domain Traffic
Engineering LSP, the A bit of the path computation server scope TLV
MUST be set. Moreover, one or more sub-TLVs MUST included within the
PCSD sub-TLV, each sub-TLV identifying an AS number. Each sub-TLV
will have 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AS-domain sub-TLV format
The AS-domain sub-TLV type is 4, length is 4 octets, and the value is
the AS number identifying the AS for which the PCS can compute inter-
domain TE LSP paths (TE LSP having their destination address in this
domain). 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 PCS can compute TE LSP path such that the
destination address of the TE LSP belong to this set of ASes.
Vasseur 6
Internet draft draft-vasseur-mpls-pcsd-discovery-00.txt June 2002
5. Elements of procedure
The PCSD TLV is carried within the IS-IS LSP.
IS-IS is an intra domain routing protocol. In networks having
multiple IS-IS levels, the elements of procedures for the
announcements of the PCSD TLVs by L1, L2 and L1L2 routers are the
following:
- If the PCS can compute intra-area TE LSP the L bit of the path
computation server scope sub-TLV must be set,
- If the PCS can compute inter-area TE LSP the I bit of the path
computation server scope sub-TLV must be set,
- If the PCS can compute inter-AS TE LSP the A bit of the path
computation server scope sub-TLV must be set,
Note: if the PCS can both compute intra and inter-area TE LSP paths,
both the L and I bits of the path computation server scope TLV must
be set. The flags are not exclusive.
Mode of operation on L1L2 routers
Any L1L2 routers receiving an LSP containing a PCSD TLV MUST:
- determine the values of the L, I and A bits flag of the Path
computation server scope sub-TLV,
- if L=1, I=0, A=0: the PCSD TLV MUST not be included in any
generated LSP,
- if either I or A is not equal to 0, the PCSD TLV MUST be
included in any generated LSP into other levels with L=0, I and
A unchanged,
Example
<-----------------AS1----------------->
R1(L1)------R3(L1L2)*-----R4(L1L2)*----| ------------
| | | | | |
| S1 | S2 | ASBR1*--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 PCS for level 1 only
- R5 is a PCS for intra and inter-area TE LSP path computation for
both levels
Vasseur 7
Internet draft draft-vasseur-mpls-pcsd-discovery-00.txt June 2002
- R4 is a PCS for inter-area TE LSP path computation only for both
levels
- S1 is a PCS for level 1 only
- S2 is a PCS for the whole AS
- ASBR1 is a PCS for inter-AS TE LSP 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 PCSD TLV with:
o The L bit of the path computation server scope TLV set,
o The I and A bits of the path computation server scope TLV
cleared.
- S2 originates a level 2 LSP containing a PCSD TLV with:
o Both the L and I bit of the path computation server scope TLV
set,
o The A bit of the path computation server scope TLV cleared,
- ASBR1 originates a level1 LSP containing a PCSD TLV with:
o The L and I bits of the path computation server scope TLV
cleared,
o The A bit of the path computation server scope TLV set,
o One AS-domain sub-TLV within the PCSD sub-TLV with AS number
= AS2
- R3 originates:
* a level 1 LSP containing:
o a PCSD TLV describing its own PCS capability with:
- The L bit of the path computation server scope TLV
set,
- The I and A bits of the path computation server scope
TLV cleared,
o the S2's PCSD TLV (with L bit of the path computation server
scope TLV cleared - I and A bit unchanged)
o the ASBR1's PCSD TLV (unchanged)
* a level 2 LSP including no PCSD TLV
- R5 originates:
* a level1 LSP containing:
o a PCSD TLV describing its own PCS capability with:
- The L and I bits of the path computation server scope
TLV set,
- The A bit of the path computation server scope TLV
cleared,
o the S2's PCSD TLV (with L bit of the path computation server
scope TLV cleared - I and A bit unchanged)
o the ASBR1's PCSD TLV (unchanged)
Vasseur 8
Internet draft draft-vasseur-mpls-pcsd-discovery-00.txt June 2002
* a level 2 LSP containing a PCSD TLV describing its own PCSD
capability with:
o Both the L and I bit of the path computation server scope TLV
set,
o The A bit of the path computation server scope TLV cleared.
The receipt of an LSP containing a new PCSD TLV never triggers an
SPF calculation.
When an LSR or a dedicated path computation server is newly
configured as a PCS, the corresponding PCSD TLV MUST be immediately
flooded.
When an LSR or a dedicated path computation server is loosing its
path computation server capability or when one of its PCSD
capabilities changes, the IS-IS LSP MUST be immediately flooded.
6. Interoperability with routers non supporting this capability
There should not be any interoperability issue with routers non
supporting the PCSD TLV. A router non supporting this extension will
silently ignore the PCSD TLV.
7. Security Considerations
No new security issues are raised in this document.
8. Acknowledgments
The authors would like to thank Stefano Previdi and Mike Shand for
their valuable comments.
9. References
[1] ISO 10589, "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)" [Also republished as RFC 1142]
[2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual
environments", R.W. Callon, December 1990
[3] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-
IS", T. Li, T. Przygienda, H. Smit, October 2000.
[4] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D.
Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus,
September 1999.
Vasseur 9
Internet draft draft-vasseur-mpls-pcsd-discovery-00.txt June 2002
[5] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering",
draft-ietf-isis-traffic-04.txt (work in progress)
[6] Generalized MPLS Group, "Generalized MPLS - Signaling
Functional Description", draft-ietf-mpls-generalized-signaling-
04.txt (work in progress)
[7] "Routing Extensions in Support of Generalized MPLS",
draft-many-ccamp-gmpls-routing-01.txt (work in progress)
[8] "Three-Way Handshake for IS-IS Point-to-Point
Adjacencies", draft-ietf-isis-3way-05.txt (work in progress)
[9] "Restart signaling for ISIS", draft-ietf-isis-
restart-00.txt (work in progress)
[10] "Generalized MPLS Signaling - RSVP-TE Extensions",
draft-ietf-mpls-generalized-rsvp-te-06.txt (work in progress)
[11] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[12] Vasseur et al, "RSVP Path computation request and reply
messages ", draft-vasseur-mpls-computation-rsvp-te-03.txt, work in
progress.
[13] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE",
Internet Draft, draft-ietf-mpls-lsp-hierarchy-06.txt, work in
progress.
[14] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in
RSVP-TE", Internet Draft, draft-ietf-mpls-rsvp-unnum-01.txt, February
2001
[15] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling
Functional Description", Internet Draft, draft-ietf-mpls-generalized-
signaling-02.txt,
February 2001.
[16] "IS-IS Extensions in Support of Generalized MPLS", draft-ietf-
isis-gmpls-extensions-12.txt, work in progress.
[17] Braden, R. Ed. et al, "Resource ReserVation Protocol-- Version 1
Functional Specification", RFC 2205, September 1997.
[18] Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[19] Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini S.,
"RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
Vasseur 10
Internet draft draft-vasseur-mpls-pcsd-discovery-00.txt June 2002
[20] Le faucheur, "Use of IGP Metric as a second TE Metric",
Internet draft, draft-lefaucheur-te-metric-igp-00.txt.
[21] Fedyk D., Ghanwani A., Ash J., Vedrenne A. "Multiple Metrics
for Traffic Engineering with IS-IS and OSPF", Internet draft,
draft-fedyk-isis-ospf-te-metrics-01.txt
[22] T. Przygienda, "Reserved TLV Codepoints in ISIS", draft-ietf-
isis-wg-tlv-codepoints-01.txt
8. Author's Addresses
JP Vasseur
CISCO Systems, Inc.
11, rue Camille Desmoulins
92782 Issy les Moulineaux Cedex 9
FRANCE
Email: jpv@cisco.com
Vasseur 11