One document matched: draft-lee-mpls-path-request-04.txt
Differences from draft-lee-mpls-path-request-03.txt
Internet Engineering Task Force CY Lee
INTERNET DRAFT S Ganti
Expires June 2003 B Hass
V Naidu
November 2002
Path Request and Path Reply Message
<draft-lee-mpls-path-request-04.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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This draft specifies the interface between an entity requesting an
explicit route between two end-points (Path Query Entity) and another
entity computing the explicit route (Path Computation Entity)
1. ID Summary for sub-IP Area
http://psg.com/lists/idsummary/idsummary.2001/msg00109.html
1.1 SUMMARY
The draft describes a scalable approach, using a path query
message/signalling to obtain constrained routes (including diverse
routes) in a flat network(eg single area) or multiple hierarchy
networks (e.g multiple areas in OSPF). The approach describes in this
draft allows a router to query routers (e.g. Area Border Routers),
which have the TE link state information necessary to compute the
disjoint route. A router may also query another router within an area
if it is not capable of doing certain path computation or if it does
not have the required information to compute a constrained route
within an area.
1.2 RELATED DOCUMENTS
draft-ash-multi-area-te-reqmts-00.txt
draft-lee-mpls-te-exchange-02.txt
draft-lee-ccamp-rsvp-te-exclude-route-01.txt
draft-kompella-mpls-multiarea-te-01.txt
draft-dharanikota-interarea-mpls-te-ext-01.txt
draft-venkatachalam-interarea-mpls-te-00.txt
1.3 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
It fits in the CCAMP WG.
1.4 WHY IS IT TARGETED AT THIS WG
This draft belongs in CCAMP as one of the needed protocol extensions
for multi-area te, as called for by the requirements in [HIER-REQ].
The draft provides a means to obtain constrained route in a scalable
manner within an area and in multiple areas, enabling diverse route
computation in multiple areas and improving the scalability of the TE
function, in general. The approach is also applicable to TE across
AS.
1.5 JUSTIFICATION
There were discussions in the TE WG about this draft. The consensus
was such a mechanism is required. Some suggestions on the list were
to modify existing protocols (e.g SNMP, COPS, RSVP-TE, CR-LDP, BGP)
for this mechanism. The authors have looked into some of the
suggested protocols and is updating the draft on this issue. In
addition, http://www.ietf.org/internet-drafts/draft-ash-ccamp-multi-
area-te-reqmts-00.txt describes initial requirements for protocol
support of multi-area TE of which a query functionality such as the
one described in this draft is required.
2. Overview
This draft specifies the interface between an entity requesting an
explicit route between two end-points (Path Query Entity) and another
entity providing the explicit route (Path Computation Entity) These
entities may reside on the same node or on different nodes in a
network. The end-points may be the source or destination in the path
or the intermediate points (eg the end-points of a segment of the
path) in the path.
==================== Request an explicit route ==============
| Path Computation | <------------------------- | Path Query |
| Entity | | Entity |
| (PCE) | | (PQE) |
| | --------------------------> | |
=================== Return an explicit route ==============
object
This interface is required by a node e.g a Label Edge Router (LER)
which does not have all the constraint information required to
compute an explicit path to the destination. For instance to
establish a route across different areas or network boundaries, an
LER may query the transit border router (which has the constraint
information to the destination or for at least part of the way to the
destination). The transit border router computes and return the
explicit routes satisfying the set of specified constraints.
If the constraint aggregated routes from another area or network is
not available the transit border router for the shortest path to the
destination, is queried. If the constraint aggregated routes from
another network area is available, the transit border router for the
constraint path may be queried.
The transit border router may recurse this query for the constraint
explicit path to the next transit border router to the destination.
If a border router recurses this query, it should concatenate the
explicit routes returned by the next transit border router to the
explicit routes that it computed, before sending the explicit path to
the querier. [Note: A border router (eg inter-domain) may choose to
return a loose segment instead and may cache the explicit route in
its domain to facilitate the subsequent path setup or it may expand
the loose segment during path setup. This is FFS]
3. Path Request and Reply Message
A one time client query and server response message is used here.
This draft describes the TLVs required for the Path Request and Reply
Message. A Path Request or Reply message is encapsulated in TCP, the
destination address is set to the path computing entity IP address
and the port number is set to a TBA value by IANA for this purpose.
A Path Request or Reply message is optionally authenticated using the
TCP MD5 Signature Option [RFC2385] and is described further in
Section 5
It should be noted that the TLVs described here can be adapted for
specific protocols (such as COPS, SNMP, RSVP-TE, CR-LDP or BGP MPLS)
The messages are: Path Request Message and Path Reply Message.
Existing TLVs already defined in various drafts are used here. The
new TLVs required are described below.
[Note: TBA means To be assigned by IANA]
3.1 Path Request Message
A Path Query Entity sends a Path Request Message, encapsulated in a
TCP header to the Path Computation Entity.
The Path Request Message contains the following mandatory fields:
The encoding for the Path Request message is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Path Request (TBA) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source - ER-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination - ER-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U Bit - as defined in [LDP]
F Bit - as defined in [LDP]. This bit is applicable when a PCE need
to query another PCE. For e.g. a PCE may act as a PQE and queries
another ABR to get the rest of the route (which the PCE has no
visiblity) to a destination.
Message ID - 32-bit value used to identify this message.
Source Address - the source end of the path or the segment specified
by the ER-Hop TLV defined in [CR-LDP] [Note: source, destination may
refer to intermediate points in a path, eg the end-points of a loose
segment of a path]
Destination address - the destination end of the path or the segment
specified by the ER-Hop TLV
Multiple Source and Destination Address TLV pairs may be specified.
The Path Request Message may contain the following optional fields:
Traffic Parameters TLV, as specified in [CR-LDP]. Bandwidth encoding
defined in [GEN-MPLS] are set in the Peak and Committed Data Rate
fields of the Traffic Parameters TLV
Resource Class TLV (4 octets) - as defined in [OSPF-TE]
LSP Encoding Type TLV (8 octets) - defined in Section 4.
Disjoint Route TLV (variable length) - contain one or more ER-TLV
3.2 Path Reply Message
The Route Response Message returns a set of explicit route. Multiple
ER-TLVs may be returned. The explicit route returned is as defined
in [CR-LDP] - the Explicit Route TLV (ER-TLV) and consists of
Explicit Hop TLV (ER-Hop TLV).
If a path is found, the full route consisting of the ERO source, all
intermediate nodes (links, nodes, ASes, labels) and the destination
is returned in the ER-TLV.
If no path satisfying the constraints is found, no ER-TLV is
returned. A Status TLV, as defined in [LDP] indicating a Status Code
(e.g."Success", "No route", "Unknown TLV") may optionally be
returned.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Reply (TBA) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER- TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID - the 32 bit value of the Message ID of the corresponding
Path Request Message
ER-TLV - contains the path computed from source to destination
4. Additional TLVs
4.1 Number of Disjoint Paths TLV
This TLV specifies the number of disjoint paths requested.
The format for the Number of Disjoint Paths TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| # Disjoint Paths TLV (TBA)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# Disjoint | |
|Paths Requested| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2 Disjoint Route TLV
This specifies that the path requested must not traverse any of the
route (node, link, AS or label) specified in the Disjoint Route TLV.
Multiple ER-TLVs may be included if desired.
The format of the Disjoint Route TLV is identical to ER-TLV, with the
exception that the 'Type' field in the TLV is TBA. This new Type
indicates that all ER-Hops specified must not be used in the path
computation. The 'L' bit in an ER-Hop should be ignored.
The XRO and EXRS specified in [XRO] may be adapted for this purpose
as well.
4.3 LSP Encoding TLV
The format of a LSP Encoding TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| LSP Encoding TLV (TBA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Encoding, Switching Type and G-PID are as defined in [GEN-MPLS]
5. Authenticity and Integrity of Path Request and Reply Messages
To protect against the introduction of spoofed TCP segments into a
Path Request and Reply connection, the TCP MD5 Signature Option
specified in [RFC2385] is optionally used here. The use of this
mechanism MUST be supported as a configurable option.
A PCE that uses the MD5 Signature Option is configured with a key
(shared secret) for each potential PQE. Each potential PQE is
configured with the corresponding shared secret. A key may be a
password or it may be generated from a Master Key and the PCE or PQE
IP address. Key management is beyond the scope of this draft. An
implementation may leverage the authentication option and shared
secret configured for other protocols for this purpose.
A PCE or PQE applies the MD5 algorithm as specified in [RFC2385] to
compute the MD5 digest for a TCP segment to be sent to a peer. This
computation makes use of the peer password as well as the TCP
segment.
When a PCE or PQE receives a TCP segment with an MD5 digest, it
validates the segment by calculating the MD5 digest (using its own
key) and compares the computed digest with the received digest. If
the comparison fails, the segment is dropped without any response to
the sender.
6.0 Acknowledgment
The authors would like to thank Neil Gammage, Anand Srinivasan, Jeff
Pickering for their helpful comments and suggestions. Section 5 is
adapted from Section 2.9. of [LDP].
References
[Slides]
http://http://www.ietf.org/proceedings/00dec/slides/TEWG 6/index.html
[HIER-REQ] Wai Sum Lai, et. al., Network Hierarchy and
Multilayer Survivability, work in progress.
[TE-REQ] http://search.ietf.org/internet-drafts/draft-ash-
multi-area-te-reqmts-01.txt
[TE-X] http://search.ietf.org/internet-drafts/draft-lee-
mpls-te-exchange-00.txt
[XRO] http://www.ietf.org/internet-drafts/draft-lee-
ccamp-rsvp-te-exclude-route-01.txt
[OSPF-TE] http://search.ietf.org/internet-drafts/draft-katz-
yeung-ospf-traffic-03.txt
[LDP] ftp://ftp.isi.edu/in-notes/rfc3036.txt
[CR-LDP] http://search.ietf.org/internet-drafts/draft-ietf-
mpls-cr-ldp-04.txt
[RSVP-TE] http://search.ietf.org/internet-drafts/draft-ietf-
mpls-rsvp-lsp-tunnel-09.txt
[GEN-MPLS] http://search.ietf.org/internet-drafts/draft-
generalized-mpls-signaling-00.txt
[GMPLS-RSVP] http://search.ietf.org/internet-drafts/draft-ietf-
mpls-generalized-rsvp-te-06.txt
[GMPLS-LDP] http://search.ietf.org/internet-drafts/draft-ietf-
mpls-generalized-cr-ldp-05.txt
[strand1] John Strand, Angela Chiu, Robert Tkach, Issues for Routing
in the Optical Layer, IEEE Communications Magazine, February 2001.
[strand2] John Strand, Yong Xue, Routing for Optical Networks With
Multiple Routing Domains oif2001.046
[sudheer1] Senthil K. Venkatachalam, Sudheer Dharanikota, "A
Framework for the LSP Setup Across IGP Areas for MPLS Traffic
Engineering, work in progress.
[sudheer2] Senthil K. Venkatachalam, Sudheer Dharanikota, Thomas D.
Nadeau, "OSPF, IS-IS, RSVP, CR-LDP extensions to support inter-area
traffic engineering using MPLS TE, work in progress.
[summary_lsa] Atsushi Iwata, Norihito Fujita, ôTraffic Engineering
Extensions to OSPF Summary LSA, work in progress.
[te_qos_routing] G. Ash, "Traffic Engineering & QoS methods for IP-,
ATM-, & TDM-Based Multiservice Networks," work in progress.
[te_framework] D. Awduche, et. al., ôOverview & Principles of
Internet Traffic Engineering work in progress.
[te_requirements] D. Awduche, et al., "Requirements for Traffic
Engineering Over MPLS," RFC2702, September 1999.
[OMPLS] http://search.ietf.org/internet-drafts/draft-kompella-
ospf-ompls-extensions-00.txt
[RFC2385] A Heffernan, Protection of BGP Sessions via the TCP
MD5 Signature Option
Authors' Information
Cheng-Yin.Lee@alcatel.com
sganti@tropicnetworks.com
BHass@nortelnetworks.com
Venkata.Naidu@Marconi.com
| PAFTECH AB 2003-2026 | 2026-04-24 01:49:21 |