Internet Engineering Task Force C-Y Lee INTERNET DRAFT S Ganti Expires: Sept 2002 B Hass V Naidu Mar 2002 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. 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 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 | | (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. 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 [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 (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 [RFC2385] A Heffernan, Protection of BGP Sessions via the TCP MD5 Signature Option Authors' Information Cheng-Yin.Lee@alcatel.com sganti@tropicnetworks.com BHass@ciena.com Venkata.Naidu@Marconi.com