Network Working Group JP Vasseur Internet Draft Carol Iturralde Expiration Date: May 2002 Cisco Systems, Inc Raymond Zhang Nadim Constantine Infonet Services Corporation Xavier Vinet Equant Satoru Matsushima Japan Telecom November 2001 RSVP Path computation request and reply messages draft-vasseur-mpls-computation-rsvp-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." 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 document describes extensions to RSVP-TE to support a new message type called a "Path computation" message. This message is to be used between an LSR and a Path Computation Server, which may be an LSR or a centralized path computation tool. An RSVP Path Computation Request message is used by the head-end LSR to send its request to the Path Computation Server. The Path Computation Server in turn sends an RSVP Path Computation Reply message containing either: - a positive reply, containing one or more paths, if the request can be satisfied. - a negative reply if no path obeying the requested constraints Vasseur et. al 1 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 can be found. The Path Computation Server may also optionally suggest new constraint values for which one or several paths could be found. There are many situations where a Path Computation Server may be used. A typical example is in the context of Inter-area MPLS TE. A head-end LSR could request that a Path Computation Server compute one or more paths obeying a specified set of constraints for a TE LSP spanning multiple areas. The path computation server could be a centralized path computation server or an ABR. Another example is the use of a Path Computation Server to compute diversely routed paths between two end points. This may be useful in the context of MPLS TE LSP Path protection or GMPLS LSP Path protection. The computation of Multi-constraints paths requires intensive CPU resources, and may be yet another usage example. Lastly, those protocol extensions could be used as a "UNI" like protocol between a CE (Customer Edge equipment) and a PE (Provider Edge equipment) where the CE is not part of the PE's IGP domain. Contents 1. Introduction 3 2. Terminology 4 3. RSVP Path Computation Request/Reply messages 4 3.1 RSVP Path Computation Request message format 5 3.2 RSVP Path Computation Reply message format 6 3.3 New RSVP objects used in Path computation messages 8 3.3.1 REQUEST_ID Object 8 3.3.2 METRIC_TYPE 9 3.3.3 PATH_COST 11 3.3.4 NO_PATH_AVAILABLE object 12 3.3.5 NB_PATH object 14 3.3.6 PATH CORRELATED object 19 3.3.7 EXCLUDE_ELEMENT object 20 3.3.8 OPAQUE object 21 4. Acknowledgment 21 5. Security Considerations 22 6. Authors' Addresses 22 Vasseur et. al 2 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 1. Introduction As mentioned in the abstract, there are various situations where a Path Computation Client may need to compute one or more paths obeying a specified set of constraints, and may ask a Path Computation Server to perform this task. This exchange does not allocate any resources, it is simply a mechanism by which a client may send a path computation request to a server and get in return a reply (positive or negative). Note also this is not related to policy. Let's briefly describe a typical sequence of events: 1) the Path Computation Client (an LSR) sends a request to the Path Computation Server (LSR, centralized path computation tool,...). A Path Computation Request message will be sent containing: a) already specified objects defined in [9] characterizing the request, and b) new objects defined in the present draft related to the request. 2) the Path Computation Request message is sent to the Path Computation Server 3) the Path Computation Server processes the request and sends either: a) a positive reply to the client containing one or more computed paths that obey the requested constraints, b) a negative reply to the client, with optionally some additional information suggesting new constraints values for which the request would have been positive. 4) the Path Computation Client can in turn: a) If the reply is positive i) If the client has sent the same request to several servers in parallel 1. Compare the reply with other replies it received from other servers. 2. Select the preferred path. Otherwise, select the returned path. ii) Establish the LSP using RSVP with extensions as defined in [9] b) If the reply is negative i) Send another request to the Path Computation Server with new constraints (potentially taking into account the returned suggested constraints values by the server, if any) ii) Wait for an answer from other servers, if any. iii) Go to 4). Vasseur et. al 3 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 2. Terminology Terminology used in this draft PCS: Path Computation Server (may be any kind of LSR (ABR, ASBR, ...) or a centralized path computation server PCC: Path Computation Client (any head-end LSR) requesting a path computation of the Path Computation Server. 3. RSVP Path computation Request/Reply messages As defined in rfc2205, an RSVP message consists of a common header followed by a body consisting of a variable number of variable- length, typed "objects". As a reminder, the common header format is: 0 1 2 3 +-------------+-------------+-------------+-------------+ | Vers | Flags| Msg Type | RSVP Checksum | +-------------+-------------+-------------+-------------+ | Send_TTL | (Reserved) | RSVP Length | +-------------+-------------+-------------+-------------+ See RFC2205 for details. One new RSVP message type is defined in this draft: a Path Computation Message. The message type is [TBD by IANA]. The Flags field is used to identify whether the message is a path computation request or a reply. Each has different contents, defined below. Flags 0x01-0x8 are reserved. A request has its flag set to [TBD by IANA] and a reply has its flag set to [TBD by IANA]. An RSVP Path Computation Request message is sent by an LSR to request one or more path computations of a Path Computation Server obeying a set of specified constraints. The objects carried in this message may include those defined in [8] and [9], new objects defined in this draft, as well as other objects that may be defined in the future characterizing, for instance, the constraints of the LSP for which one or several paths should be computed. The IP source address is the IP address of the requesting LSR and the IP destination address is the IP address of the Path Computation Server. An RSVP Path Computation Reply message is sent by the PCS to the requesting LSR (PCC) to return one or more computed Paths, if any. The object(s) carried will include one or more EROs (Explicit Route Objects), as defined in [9], plus additional objects defined in this draft. If no path can be found, the PCS reply will be negative. An ERROR_SPEC object will be carried in the reply, and optionally additional information as defined in section 3.3.4. The source IP Vasseur et. al 4 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 address will be the IP address of the PCS and the destination IP address will be the IP address of the PCC. RSVP Path computation messages are sent without the router alert option. Path computation messages should be sent in reliable mode as defined in RFC2961. This allows an acknowledgment message to be used to acknowledge the receipt of a Path computation message (request and reply). In case of message loss, the message will be fast retransmitted as defined in RFC2961. Note that the DSCP field of the IP packet carrying an RSVP Path Computation message may be set appropriately to provide the appropriate quality of service delivery to the packet. The same Path Computation Request may be sent to several PCSs. In this case, the decision process used by the PCC to select from among (possibly) multiple replies is a local decision and is beyond the scope of this document. 3.1. RSVP Path Computation Request Message Format The Path Computation Request message format is as follows: The Flags field of the common header must be set to [TBD] by IANA to identify a request. ::= [ ] [ | ] ... ] [ ] [ ] [ ] [] [] [ ] [ ... ] ::= [ ] [ ] One new (mandatory) object is defined: REQUEST_ID to identify the request. This object is also used to indicate the request's priority and LSP type. See 3.3.1 for details. The SESSION_ATTRIBUTE object (class=207, C-type=1) allows carrying setup and holding priorities, resource affinities, etc. Other constraints may also be carried in the Path Computation message. Note Vasseur et. al 5 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 that any other constraints that could be defined in the future can be expressed as new objects. The ERO object may also be present in the RSVP Path Computation Request. The reason is that the head-end may want to specify some LSR(s) that the LSP must traverse. At least one sub-object in the ERO must have its L flag bit set to 1, referring to a loose hop. The optional METRIC_TYPE object allows the PCC to specify the metric the PCS must use in its CSPF to select the "best" path obeying the requested constraints. See the METRIC_TYPE object definition in 3.3.2 for more details. The optional NB_PATH object (defined in 3.3.5) allows the PCC to specify the number of requested paths to the PCS for the specific set of constraints specified in the RSVP Path Computation Request message. 3.2. RSVP Path Computation Reply message format The Path Computation Reply message format is as follows: The Flags field of the common header must be set to [TBD by IANA] to identify a Path Computation Reply. ::= [ ] [ | ]...] [ ] [ ] [ [] ] ... [ ] [ ... ] The REQUEST_ID is the same REQUEST_ID (contains the same value) as the one contained in the Path Computation Request to which the reply corresponds. In case of a negative reply (no path obeying the constraints can be found), the PCS must send a reply containing an ERROR_SPEC object with: - ERROR_CODE [TBD by IANA] and ERROR_VALUE [TBD by IANA] - "Ipv4 Error Node address" ("Ipv6 Error Node address") set to the Ipv4 (Ipv6) address of the PCS. This must be the same IP address as was used in the Path Computation Request message. There are various reasons why the Path Computation Server may not be able to satisfy the request: - the Path Computation Request message was not valid ("unknown object class (error_code=23, "unknown object C-type Vasseur et. al 6 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 (error_code=14), "Routing problem" (error_code=24), ...), ... See [8] and [9] for details. In such a situation, the PCS must send the Path Computation Reply message without any ERO objects and without NO_PATH_AVAILABLE object. - No path can be found obeying the set of requested constraints. If no path can be found by the PCS for the specified constraints, and only in this situation, a NO_PATH_AVAILABLE object may be inserted into the RSVP Path Computation Reply message sent by the PCS. This object (defined in section 3.3.4) is optional and may specify the constraint(s) that explain(s) why no path has been found. In addition, the PCS may use the NO_PATH_AVAILABLE object to suggest new constraint values for which a path can be found. In such a situation, the Path Computation Reply message must not contain any ERO objects. Note that a Path Computation Reply message may contain several EROs if and only if several paths have been requested by the LSR in its Path Computation Request message using the new NB_PATH object (see 3.3.5). Moreover, multiple replies may be combined in the same Path Computation Reply message. This is done using a list of EROs, each following its corresponding REQUEST_ID as shown in the example below. A reply should not be delayed in order to bundle several path computation results for requests whose priority REQUEST_ID field (see 3.3.1) has been set to "high". As an example, if a PCC sends several requests: - L low priority requests with REQUEST_ID = R(i) I=1 ... L - P high priority requests with REQUEST_ID = R'(i) I=1 ... P Then the PCS MUST reply to every high priority request as soon as the computation result is completed. On the other hand, the low priority request results could be bundled in the SAME Path Computation Reply message using the following format: ... . If no path can be found for a specific request, an individual negative Path Computation Reply message must be sent for the corresponding request. A PATH_COST object (defined 3.3.3) may be inserted and follow each ERO object if and only if the PCC has requested the PCS to provide the cost of each computed path in its Path Computation Request message (the "C" bit in the flag field of the REQUEST_ID object present in the path computation request must be set). Vasseur et. al 7 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 3.3. New RSVP objects used in Path Computation messages 3.3.1. REQUEST_ID Object The REQUEST_ID object must be used in every Path Computation Request message and in every Path Computation Reply message. REQUEST_ID Class-Num is [TBD] REQUEST_ID C-Type is [TBD] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res|B|R|T|C|Pri| Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request_ID_number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 6 bits C (Cost): when set, the PCC does require the PCS to indicate the path's computed cost in its reply. T (Type of reply: Partial or complete): In a request, when set, this specifies the returned path must be complete (set of directly connected LSRs). When this bit is cleared, the returned path may be complete or partial (set of loose hops). In a reply, when set, this indicates the returned path is complete. If the returned path is partial, this bit is cleared. R (Reoptimization): when set, the PCC specifies that the request concerns a reoptimization (a new path computation for a TE LSP already in place). This requires for the PCC to provide the path of the TE LSP in place in the path computation request to avoid double counting. The ERO must be formed of strict hops only. B (Bi-directional): when set, the PCC specifies the TE LSP is bi- directional. When cleared, the TE LSP is unidirectional. Pri (Priority): 2 bits This field may be used for the requesting LSR to specify to the PCS the urgency of this request. The decision of which priority should be used for a specific request is a local matter and must be set to 0 when unused. A possible use of this field is when several computations may be requested, each having different timing requirements: typically a request for a reoptimization would have a lower priority than a re-routing request. 0x0: normal. No timing requirement specified. 0x3: high. Urgent request to be served as soon as possible. Vasseur et. al 8 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 Epoch: 24 bits Epoch is as described in RFC2961 and can be the same number. Request_ID_number: 32 bits This value (combined with the IP address of the PCC) uniquely identifies the Path Computation Request the message refers to and is incremented every time a new request is sent to the PCS. If no Path computation reply is received from the PCS, the request may be resent with the same Request_ID_number. The same Request_ID_number may be sent to different PCS's. The Path Computation Reply will be identified by the IP source address of the sender. The presence of the REQUEST_ID object is mandatory in every Path Computation Request and Reply message. 3.3.2. METRIC_TYPE The METRIC_TYPE object may be used in Path Computation Request message. This object is optional. When computing the path(s) obeying a set of specified constraints, the PCS will run a CSPF and will select the "shortest" path from the subset of the topology which meets the constraints. The shortest Path is defined as the path having the lowest cost for a specific metric. This metric can be the IGP metric, the Traffic Engineering metric, or any other metric defined in the future. See also [11] and [12] for a discussion on the use of the metric in the path computation. The METRIC_TYPE object is used by the PCC to indicate the PCS which metric to be used in its CSPF. When the METRIC_TYPE object is not present, the PCS must use the TE metric. METRIC_TYPE object format METRIC_TYPE Class-Num is [TBD] METRIC_TYPE C-Type is [TBD] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subobjects The contents of the METRIC_TYPE object are a series of variable-length data items called subobjects. The subobjects Vasseur et. al 9 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 are defined in section below. Subobjects 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ | metric_type | Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ metric_type metric_type: identifies the metric type 0x00: IGP metric 0x01: Traffic Engineering metric length The Length contains the total length of the subobject in bytes, including the metric_type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4. Subject content Both IGP and Traffic Engineering metric have the same form: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | metric_value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The metric_value subobject object will not be present in a path computation request. Note that the PCC may specify multiple metrics in its request. In such a case, the PCS must: - compute the shortest path(s) obeying the specified set of constraints for every metric, - provide in its reply the shortest path(s) for each metric since the PCC has required the shortest path for more than one metric. This means that the PCS must, for each metric type, provides the ERO and optionally the corresponding cost (see 3.3.3). A PATH_COST object will follow the ERO object in the reply that will specify the metric_type and optionally the metric_value. Vasseur et. al 10 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 3.3.3. PATH_COST The PATH_COST object is used in Path Computation Reply message. It may be desirable for the PCC to request that the PCS return not only the computed paths but also their corresponding costs. The cost of the path is defined as the sum of the link metrics (IGP or TE metric) along this path. As defined in 3.3.1, the PCC will set the "C" bit of the Flag field in the REQUEST_ID object of its Path Computation Request message to indicate the path(s) cost must be provided by the PCS in its reply (if the reply is positive). When the PCS returns one or more computed paths to the PCC: - if the "C" bit of the REQUEST_ID flag has not been set in the Path Computation Request message, the PCS may or not provide the Path(s) cost, - if the "C" bit of the REQUEST_ID flag has been set in the Path Computation Request message, the PCS must, for every ERO, include a PATH_COST object specifying the cost of the computed path for the requested metric(s). The requested metric is specified in the METRIC_TYPE Object received in the Path Computation Request. As mentioned in the previous section, there is another situation where the PCS must include a PATH_COST object for every computed ERO: when the request has been received with a METRIC_TYPE object specifying more than one metric. In this case, the PCS will also add one PATH_COST object for every ERO specifying the metric for which the ERO corresponds to the shortest path. The PATH_COST object will be made of subobjects identifying the metric type and the associated value. PATH_COST Class-Num is [TBD by IANA] PATH_COST C-Type is [TBD by IANA] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The same subobjects as previously defined will be used. The IGP metric of a computed path is defined as the sum of the IGP metrics of each link along the path. The TE metric of a computed path is defined as the sum of the TE metrics of each link along the path. Examples of METRIC_TYPE, PATH_COST Objects Vasseur et. al 11 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 In the following examples, not all optional objects are mentioned and we suppose positive answers. Example 1 Request =a, "C" bit=0x1 : TE metric The PCC sends a request for the computation of one path obeying the set of specified constraints. The returned path must be the shortest path using the TE metric and must specify the associated cost. Reply REQUEST_ID=a : metric_type="TE", metric_value=C1 (sum of the TE metric of the links along the path for ERO 1) Note: if the "C" bit is cleared in the RESQUEST_ID object of the path computation request, the PCS may (but is not required to) return the computed path(s) with PATH_COST objects. Example 2 Request =a, "C" bit=0x1 : IGP metric & TE metric The PCC sends a request for the computation of one path obeying the set of specified constraints. The returned path must be the shortest path using the TE metric. Reply REQUEST_ID=a : metric_type="TE", metric_value=C1 (sum of the IGP metric of the links along the path for ERO 1) : metric_type="IGP", metric_value=C2 (sum of the TE metric of the links along the path for ERO 2) 3.3.4. NO_PATH_AVAILABLE object The NO_PATH_AVAILABLE object may be used in Path Computation Reply message. This object is optional. Vasseur et. al 12 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 When present, it allows the PCS to: - indicate the unsatisfied constraint (the reason why no path can be found) - (optionally) suggest a new value for the constraint (the closest value of the required one) for which a path could be found. This may be used by the requesting LSR to resend a new request with the suggested value. The PCS may not be capable of suggesting a new value. NO_PATH_AVAILABLE Class-Num is [TBD by IANA] - C-Type is [TBD by IANA] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Reserved | Contraint_type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suggested_value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits 0x00: the PCS indicates the constraint for which no path can be found but does not suggest any other value for the constraint for which a path could be found. 0x01: the PCS indicates the constraint for which no path can be found and suggests another value for this constraint (as close as possible to the original requested constraint) for which a path could be found. This value is indicated in the suggested_value field. 0x02: the PCS indicates that no path can be found with the requested constraints but an unconstrained path could be found. In this case both the Contraint_type and Suggested_value fields must be set to 0. Constraint_type: 16 bits Defines the constraint for which no path has been found by the Path Computation Server. 0x0001 = no path can be found with the requested bandwidth 0x0002 = no path can be found with the requested protection 0x0003 = no path can be found with the requested class affinity attribute 0x0004 = the path-correlation requested cannot be satisfied 0x0005 = no path can be found since the LSP was requested as bi- directional Suggested_value: 32 bits The PCS may, for each constraint, suggest a value (potentially the closest to the requested constraint in the original Path computation request) for which a path could be found. In this case, the flag must Vasseur et. al 13 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 be set to 0x01. For example, if a bandwidth of X is requested by the head-end LSR and a path may be found but with a bandwidth of Y (with Y =a : flag=0x00, number_PATH=N, Path_correlation=0x02 (Node diversely routed paths) sender descriptor: bw=x, ... If just M (M (specifying a negative reply) : number_PATH=M, Path_correlation=0x02 : Flags=0x01, Constraint_type=0x0001 (bandwidth), Suggested_value=y Which means: - the reply is negative (the request cannot be satisfied with the specified constraints) - the unsatisfied constraint is "Bandwidth" - Exactly M EROs (M =a : flag=0x01, number_PATH=N=4, Path_correlation=0x02 (Node diversely routed paths) =a,b,c,d sender descriptor: bw=x, ... The PCS receives a Global path computation request for N=4 paths sharing different set of constraints. The PCS will start the computation after having received the N=4 path computation requests having the request_ID_number a, b, c and d. Request 2 =b sender descriptor: bw=y, ... Request 3 =c sender descriptor: bw=z, ... Request 3 =d sender descriptor: bw=w, ... If the request cannot be satisfied, the PCS can optionally specify: - the number of paths that could be satisfied with their respective constraints, - the set of requests that could not be satisfied in the PATH_CORRELATED object. Example: Reply 1 REQUEST_ID=b (specifying a negative reply) Vasseur et. al 18 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 : number_PATH=2, Path_correlation=0x02 : b,c : Flags=0x01, Constraint_type=0x0001 (bandwidth), Suggested_value=y' Reply 2 REQUEST_ID=c (specifying a negative reply) : Flags=0x01, Constraint_type=0x0001 (bandwidth), Suggested_value=z' Which means: - the reply is negative (the global request cannot be satisfied with the specified constraints) - just 2 requests could be satisfied - the requests whose resquest_ID_number are b and c could not be satisfied - the unsatisfied constraint for request b is "Bandwidth" - the global request could be satisfied if the request bandwidth for request b is y' and the requested bandwidth for c is z' Then the PCC could decide to resend a new global path computation request with the new suggested value. 3.3.6. PATH_CORRELATED object The PATH_CORRELATED object may be used in Path Computation Request message. This object is optional. It allows the PCC to request to the PCS the computation of N correlated paths having different set of constraints and contains the list of the REQUEST_ID of those paths. PATH_CORRELATED Class-Num is [TBD] PATH_COORELATED C-Type is [TBD] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subobjects The contents of a PATH_CORRELATED object is a series REQUEST_ID objects. Vasseur et. al 19 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 3.3.7. EXCLUDE_ELEMENT object The EXCLUDE_ELEMENT object may be used in Path Computation Request message. This object is optional. It allows the PCC to specify to the PCS another constraint related to the computed path: the exclusion of one or more network elements in the computed path. A network element may be a link, an entire node or even an Autonomous System. The EXCLUDED_ELEMENT object contains the list of network elements to exclude from the computed path. Each network element is represented as a subobject. EXCLUDE_ELEMENT Class-Num is [TBD] EXCLUDE_ELEMENT C-Type is [TBD] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subobjects The contents of an EXCLUDE_OBJECT object is a series of variable-length data items called subobjects. The subobjects are defined in section below. Subobjects 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ |NET| Type | Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ NET (Network Element Type) Defines whether the network element is a link, a node or an AS. L=0x00 the subobject identifies a link address the computed path must not traverse. L=0x01 the subobject identifies a node address the computed path must not traverse. L=0x02 the subobject identifies an Autonomous System the computed path must not traverse. Type Indicates the type of data found in the subobject. Currently defined values are: 0 Reserved Vasseur et. al 20 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 1 IPv4 prefix 2 IPv6 prefix 32 Autonomous system number Length The Length contains the total length of the subobject in bytes, including the NET, Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4. 3.3.8. OPAQUE object The OPAQUE object may be present in both Path Computation Request and Reply message types. This object is optional. The OPAQUE object may be used by the PCC to transfer information to the PCS (in a Path Computation Request message) or by the PCS to transfer information to the PCC (in a Path Computation Reply message). Opaque object may be used for future extensions and the exact content of the OPAQUE object is beyond the scope of this draft. OPAQUE Class-Num is [TBD by IANA] - C-Type is [TBD by IANA] 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 ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Type: identifies the TLV type Length: length of the value field in octets The OPAQUE object may also contain sub-TLV to be defined in the future. 4. Acknowledgment The authors would like to thank Bob Thomas, Francois Le Faucheur, Rob Goguen, Anna Charny and Ashok Naranayan for their very valuable comments. Vasseur et. al 21 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 5. Security Considerations No new security issues are raised in this document. See [8] for a general discussion on RSVP security issues. 6. References [1] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-04.txt [2] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering," draft-ietf-isis-traffic-02.txt, work in progress. [3] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", Internet Draft,draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. [4] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in RSVP- TE", Internet Draft, draft-ietf-mpls-rsvp-unnum-01.txt, February 2001 [5] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - CR-LDP Extensions", Internet Draft, draft-ietf-mpls-generalized-cr-ldp- 01.txt, February 2001. [6] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized-signaling- 02.txt,February 2001. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [8] Braden, R. Ed. et al, "Resource ReserVation Protocol-- Version 1 Functional Specification", RFC 2205, September 1997. [9] Awduche, D.O., Berger, L., Gan, D.-H., Li, T., Swallow, G.,and Srinivasan, V., "RSVP-TE: Extensions to RSVP for LSP Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-09.txt, August 2001. [10] Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini S., "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [11] Le faucheur, "Use of IGP Metric as a second TE Metric", Internet draft, draft-lefaucheur-te-metric-igp-01.txt. [12] 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 [13] Kompella, K., Rekhter, Y., Vasseur, JP., "Multi-area MPLS Traffic Engineering", Internet Draft, draft-kompella-mpls-multiarea- te-02.txt, February 2001 Vasseur et. al 22 draft-vasseur-mpls-computation-rsvp-01.txt November 2001 [14] Ash J. et al, "Requirement for Multi-area TE", Internet Draft, draft-ash-multi-area-te-reqmts-01.txt, November 2001 Authors' Address: JP Vasseur Cisco Systems, Inc. 11, rue Camille Desmoulins 92782 Issy les Moulineaux Cedex 9 FRANCE Email: jpv@cisco.com Carol Iturralde Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 USA Email: cei@cisco.com Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA Office: +310-335-1039 Email: raymond_zhang@infonet.com Nadim Constantine Infonet Services Corporation 2160 East Grand Avenue El Segundo, CA 90245 U.S.A. office: +310-335-2664 Email: nadim_constantine@infonet.com Xavier VINET EQUANT 9 rue du ChŠne Germain - BP 80 35512 Cesson Sevigne cedex FRANCE Email : xavier.vinet@equant.com Satoru Matsushima Japan Telecom 4-7-1, Hatchobori, Chuo-ku Tokyo, 104-8508 Japan Phone: +81-3-5540-8214 Email: satoru@japan-telecom.co.jp Vasseur et. al 23