One document matched: draft-lee-mpls-path-request-02.txt-14936.txt
Differences from 02.txt-01.txt
Internet Engineering Task Force C-Y Lee
INTERNET DRAFT S Ganti
B Hass
V Naidu
G Ash
Nov 2001
Path Request and Path Reply Message
<draft-lee-mpls-path-request-02.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 memo 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). Without a similar approach, in
order to compute diverse routes spanning multiple areas, either TE
LSAs are flooded in the whole AS (all areas) or all the TE LSAs must
be downloaded from all areas. 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
http://www.ietf.org/internet-drafts/draft-ash-multi-area-te-reqmts
-00.txt
http://search.ietf.org/internet-drafts/draft-kompella-mpls-
multiarea-te- 01.txt draft-dharanikota-interarea-mpls-te-ext-01.txt
draft-venkatachalam-interarea-mpls-te-00.txt
http://search.ietf.org/internet-drafts/draft-lee-mpls-te-exchange-
01.txt
1.3 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
It fits in the CCAMP WG
Applications +-------+ +-------+ (new) Hour glass
that use CCAMP: | TE-WG | | PPVPN | ... /
+-------+ +-------+ /
+----------------------+ /
| CCAMP | /
|-----------+----------| /
/ | C | M --|------ IGP LSA ext
/ | control | measure |
/ +----------------------+
Technologies to / +----+ +----+ +----+ +----+ +----+
measure/control:/ |MPLS| |OPT | |RPR | |ATM | | FR |...
+----+ +----+ +----+ +----+ +----+
1.4 WHY IS IT TARGETED AT THIS WG
>From the charter of TE-WG: "The working group also serves as a
general forum for discussing improvements to IETF protocols to
advance the traffic engineering function.
The working group may also consider the problems of traffic
engineering across autonomous systems boundaries."
This draft belongs in CCAMP as one of the needed protocol extensions
for multi-area te, as called for by the requirements, [hierarchy-
restoration-requirements].
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 memo 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 |
| | --------------------------> | |
=================== 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. The Path Request 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 value that is being reserved for this
purpose. 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 TLV added is : Discrete Bandwidth Required TLV Other optional
TLVs will be defined in future.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Path Request (0x0420) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source - ER-Hop TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination - ER-Hop TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]
Resource Class TLV (4 octets) - as defined in [OSPF-TE-EXT]
Encoding Type TLV (4 octets) - defined as Bandwidth Encoding in
[GEN-MPLS]
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)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Path Request (0x0421) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Additional TLVs
4.1 Number of Disjoint Paths TLV
The 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| # Disjoint Paths TLV | Length |
| | | (0x0850) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# Disjoint | |
|Paths Requested| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2 Disjoint Route TLV
This specifies that the path requested should not traverse the route
specified in the Disjoint Route TLV, an enhanced ER-TLV. Multiple
ER-TLVs may be included if desired. A bit in the Reserved field in
the ER-Hop is allocated to indicate that the ER-Hop should not be
used in the path computation. If this bit is set, the 'L' bit should
be ignored.
5.0 Acknowledgment
The authors would like to thank Neil Gammage and Anand Srinivasan for
their helpful comments and suggestions.
References
[Slides] http://http://www.ietf.org/proceedings/00dec/slides/TEWG-6/index.html
[hierarchiy_restoration_requirements] 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
[OSPF-TE] http://search.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-03.txt
[CR-LDP] http://search.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-0404.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-ashwood-generalized-mpls-signaling-00.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 (for a copy send an email request to jls@research.att.com).
[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
[RSVP-CONS] http://search.ietf.org/internet-drafts/draft-kompella-mpls-rsvp-constraints-00.txt
Authors' Information
Cheng-Yin Lee leecy@sympatico.ca
Sudhakar Ganti sganti@tropicnetworks.com
Barry Hass BHass@ciena.com
Venkata Naidu Venkata.Naidu@Marconi.com
Gerald Ash gash@att.com
| PAFTECH AB 2003-2026 | 2026-04-24 03:22:34 |