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 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