HariKishan Desineni Internet Draft Kameswara Rao Avasarala Document: draft-kishan-lsp-btrace-00.txt Ericsson Expires: July 2002 February 2002 LSP backtrace using MPLS-LDP/CR-LDP draft-kishan-lsp-btrace-00.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 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" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. TO view current status of any Internet-Draft, please check the "1id- abstracts.txt" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract This document describes the encoding and procedures for new LDP messages, the back trace message and back trace reply message. The back trace message is sent for an established LSP. The back trace message can be used for LDP LSPs as well as for CR-LSPs. The data requested is encoded into the back trace reply message. 1. Introduction The original Multiprotocol Label Switching (MPLS) architecture [MPLS-ARCH] was been defined to support the forwarding of data based on a label. The MPLS architecture does not assume a single label distribution protocol. A number of different label distribution protocols are being standardized. This draft describes the backtrace mechanism for an LSP or CR-LSP. It specifies procedures and encoding for the new messages added for the back trace mechanism. Extensions to RSVP-TE to provide the same functionality are subject for future study and will be covered in future draft versions. The new LDP messages are: Backtrace Message, Backtrace-Reply Message. The following new TLVs are added to accommodate the encoding for the new backtrace messages: - Tree TLV - Ingress Flags TLV - Reserved Bandwidth TLV - Aggregation TLV LDP uses the TCP transport for session, advertisement and notification messages; i.e., for everything but the UDP-based discovery mechanism. The messages, which are added to support the back-trace mechanism, are sent over TCP as well. 2. Overview 2.1. LDP Overview Label Distribution Protocol (LDP) defined in [LDP Specification] contains a set of procedures and messages by which Label Switched Routers (LSR) establish Label Switch Paths (LSP) through a network by mapping network layer routing information directly to data-link layer switched paths. LDP associates a Forwarding Equivalence Class LSP Backtrace using MPLS-LDP/CR-LDP February 2002 (FEC) with each LSP it creates. The FEC associated with an LSP specifies which packets are mapped to that LSP. 2.2. CR-LDP Overview As described in [Constraint-Base LSP Setup using LDP], Constraint Base Routing (CR-LDP) offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. 3. LDP Message Structure Overview As described in LDP Specification draft, all LDP messages have the following format: U bit Unknown message bit.Upon receipt of an unknown message, if U is clear (=0), a notification is returned to the message originator; if U is set (=1), the unknown message is silently ignored. Message Type Identifies the type of message Message Length Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters. 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| Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Mandatory Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LSP Backtrace using MPLS-LDP/CR-LDP February 2002 Message ID 32-bit value used to identify this message. Used by the sending LSR to facilitate identifying notification messages that may apply to this message. An LSR sending a notification message in response to this message should include this Message Id in the Status TLV carried by the notification message. Mandatory Parameters Variable length set of required message parameters. Some messages have no required parameters. For messages that have required parameters, the required parameters MUST appear in the order specified by the individual message specifications in the sections that follow. Optional Parameters Variable length set of optional message parameters. Many messages have no optional parameters. For messages that have optional parameters, the optional parameters may appear in any order. 4. Behavior of LSRs with constraints in handling the back-trace request messages: Upon receiving a back-trace request message, an LSR has to behave according to its configuration constraints in handling the back-trace messages and returning the queried information. The following cases were identified: - The LSR does not support the code to handle the messages for the back-trace mechanism LSP Backtrace using MPLS-LDP/CR-LDP February 2002 - The LSR supports the code to handle the messages for the back-trace mechanism, but it is configured not to return any data - The LSR supports the code to handle the messages for the back-trace mechanism, but it is configured not to return part of the queried data - The LSR supports the code to handle the messages for the back-trace mechanism, and it is configured to return all the data, which is queried. The proposed mechanism provides flexibility to handle each of the above cases. 4.1. LSR does not support the back-trace messages In this case, the LSR has to behave as if it received an unknown message type. It has therefore to honor the U bit. 4.2. LSR cannot share any information In this case, the LSR is able to decode and process the back-trace messages. However, it is configured to hide all the data. It should propagate the message to the upstream LSP peers. When back-trace reply message is received from upstream, the LSR is requested to propagate the reply message downstream after it encodes the zero- length TLVs for the queried data. When the egress receives back the reply, it can identify which TLVs are empty; it can therefore ignore the zero- length TLVs and process the rest of the data. Note: Zero length TLV encoding can be used for all types of queried information except the merge information, True Ingress information and LSP root node information in the Tree TLV. For more information on Tree TLV, see the section on "Tree TLV". For more information on true ingress information see the section "True Ingress Flags TLV". For more information about merge flags information see the draft "LDP query message description". 4.3. LSR cannot share some of the queried information In this case, the LSR is able to decode and process the back-trace messages. It has to propagate the back-trace messages. In the backtrace reply message, it has to encode values for the data types that it is willing to return and zero- length TLVs for values for the data that is hidden. Note: Zero length TLV encoding can be used for all types of queried information except the merge information, True Ingress information and LSP root node information in the Tree TLV. When a LSR is configured to hide its sibling information, it has to encode sibling count as 255 in tree TLV. For more information on Tree TLV, see the section on `Tree TLV'. For more information on true ingress LSP Backtrace using MPLS-LDP/CR-LDP February 2002 information see the section `Ingress Flags TLV'. For more information about ingress flags information see section `Ingress Flags TLV'. 4.4. LSR can share the queried back-trace information This is the normal case for an LSR. In this case, the LSR's behavior has to follow the back-trace and back-trace reply procedures described in the following sections. The decision that an LSR can share the back-trace information has to be controlled through local configuration. 5. Back-Trace Message This section describes the back-trace message and its encoding and procedures. This message is meant to gather information about an LSP-tree for a FEC. It can be sent at any time for an established LSP. The back-trace message can be used to gather information about: - LSRs, which form the LSP-Tree of a FEC. - Labels used along the LSP-Tree. - Information about which LSRs are merging points in the LSP Tree. - Unreserved bandwidth (as described in `Improving Topology Data Base Accuracy with LSP feedback') along LSPs forming the LSP-Tree. - Allocated bandwidth for LSPs forming the LSP-Tree. (This will be useful for MPLS network monitoring purpose). See `Reserved Bandwidth TLV' section. - Information about FEC aggregation occurring at LSRs in the LSP-Tree. - Anything that is needed in future for MPLS network management, which can be computed and encoded in a TLV. The back-trace information is encoded in the back-trace reply message, which is sent back downstream, as a response to the back- trace message. 5.1. Back-trace message encoding The encoding for the back-trace message is: LSP Backtrace using MPLS-LDP/CR-LDP February 2002 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| BackTrace (TBA) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Count TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. FEC TLV The FEC TLV must include only one FEC element corresponding to the FEC being back-traced. Query TLV What to query. This TLV is used to query additional information about LSPs in the LSP-Tree. See [QUERY] for Query TLV for encoding. Also see `Query TLV extensions' section. Hop Count TLV Specifies the number of LSR hops that can still be traversed before the message is dropped. It is initialized to the max value of 255 (or the configured value, if any). Every LSR that receives the back-trace message has to subtract 1 from the Hop Count value. The Query message should be dropped if the hop count value becomes zero. Optional Parameters No optional parameters are defined at present for this message. 5.2. Back-Trace Message Procedures The LSR Egress initiates the back-trace message. It populates the Query TLV Parameters according to what kind of information it wants to gather. Back-trace for a LSP is done by its FEC. Upon receiving a back-trace Message, an LSR decodes the FEC and finds the out going label to identify the LSP is being back-traced. If it cannot find the LSP, it sends back a Notification message with `No LSP to back-trace' status. Otherwise, it finds the in coming set of labels, which are merged into the already found out going label. Then the LSR computes the upstream LSR peer set `S', corresponding to each incoming label in the in coming label set. Then it computes another set `P', which LSP Backtrace using MPLS-LDP/CR-LDP February 2002 is a subset of `S' containing only the upstream LSRs, which were advertised a label binding for a FEC, which in-turn either subsumes the FEC received in the back-trace message or is subsumed by the FEC in the back-trace message. After computing the upstream LSR peer set, the LSR propagates the back-trace request message to all the members of set `P' computed as described in the above paragraph. Sometimes it may be necessary to send more than one back-trace request to the same member of the set `P'. This situation arises when a LSR advertises several FEC-Label bindings to an upstream peer, where each of the advertised FECs may either subsume or be subsumed by the FEC received in back trace request. A mechanism to find the upstream peer for an incoming label can be found in [LDP-STATE]. When the back-trace request message gets to a tunnel, it has to be propagated to the upstream LSP peer at the same LSP level. I.e., the back-trace request message should never be propagated to LSP peers at a level different from the LSP level at which it was received. Upon receiving the back-trace message, the Ingress node has to respond with a back-trace reply message. The back-trace reply message contains the Query TLV, which was received in the back-trace message. The Query TLV tells the LSRs along the path which information is being queried and allows intermediate LSRs to piggy back their own queried information on the back-trace reply message. 6. Back-trace Reply Message This message is propagated downstream. It is sent in response to a back-trace request message. The egress, which initiated the back- trace message, is interested in gathering information from all the nodes in the LSP tree for the FEC. However, there are situations in which the back-trace message does not reach all the ingress LSRs for the FEC being back-traced. In these scenarios it would be useful if the egress LSR gathered at least some information about the LSRs, which are along the path, up to the one that failed. If the back- trace reply message is full, TCP will take care of it by segmenting and re-assembling the message. Back-trace reply message is described in the following sections. 6.1. Back-trace reply message encoding This message can be generated by any LSR along the LSP-Tree. It is sent downstream, by each LSR along the path. The encoding for the back-trace reply message is: LSP Backtrace using MPLS-LDP/CR-LDP February 2002 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| Backtrace -Reply (TBA) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MessageId TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. Query TLV What was queried? See [QUERY] TLV for encoding and `Query TLV extensions' section. Message Id TLV The value of this parameter is the message id of the corresponding Query message. Optional Parameters This variable length field contains 0 or more parameters, each Encoded as a TLV. The optional parameters are: Optional Parameter Length Value Query Label TLV var See Query Label TLV section in[QUERY] IPV4/6 specified link feedback TLV var See [TOPOLOGY] Query Merge Flags TLV var See Query Merge Flags TLV section in [QUERY] Ingress Flags TLV var See Ingress Flags TLV Section Reserved Bandwidth TLV var See Reserved Bandwidth TLV Section Aggregation TLV var See `Aggregation TLV' Section For simplicity we reuse here TLV types defined for CR-LDP, LDP and [QUERY]. LSP Backtrace using MPLS-LDP/CR-LDP February 2002 They are: - IPV4/6 specified link feedback TLV - Generalized Label TLV (used in the Query Label TLV encoding) - Query Label TLV - Query Merge Flags TLV Ingress Flags TLV is a list of pair of bits. It has variable length and every two bits in the mask will correspond to an LSR along the LSP-Tree. Its length is rounded up to the next byte. If Q7 is set in Query TLV, every LSR along the path will have to set its corresponding bits in the mask. The bits have to be set in the same order as the nodes in the tree TLV. Reserved bandwidth TLV informs the bandwidth allocated for the LSP over the out-bound link. It Q4 is set in Query TLV, every LSR along the LSP-Tree will have to fill this information, if it is configured to reveal such information. If an LSR is configured to hide such information, a ZERO Length TLV has to be encoded. For more information on this TLV, see section `Reserved Bandwidth TLV'. Aggregation TLV informs the FEC aggregation occurring along the paths in the LSP-Tree. If Q5 flag is set in Query TLV, every LSR along the LSP-Tree will have to fill this information, if it is configured to reveal such information. If the LSR is performing FEC aggregation, the encoded information includes a FEC, which is either subsumes or subsumed by the FEC being back-traced. For more information on this TLV, see section `Aggregation TLV'. The information encoded in the above TLVs s by each LSR, should be in the same order as its information in tree TLV. For more information for the TLV encoding of the TLVs which are reused, please see CR-LDP draft, LDP draft, [TOPOLOGY] and [QUERY]. 6.2. Back-Trace Reply Message Procedures A Back-Trace reply message can be generated by any node, which receives a back-trace request message, if the node is able to identify an LSP for the FEC received. If the node is not able to identify the FEC, it replies with a notification message with `No LSP to back-trace' Status. If the node is true Ingress of the LSP, it can immediately send the back-trace reply to the downstream LSP peer. If the node is not the Ingress of the LSP, it waits for the responses from LSRs in the upstream LSP peer (siblings) set `P', computed as described in section 5.2. The time-out period for the responses from upstream LSP peers is implementation dependent and should be locally configurable. Once the time-out period expires, the node should generate a back- trace reply with whatever information it has gathered from the upstream LSP peers that have responded within the time-out interval. LSP Backtrace using MPLS-LDP/CR-LDP February 2002 The gathered LSP sub-tree information is encoded as tree TLV in back- trace reply message. Responses received after time-out interval should be ignored. If the node is not able to propagate the back-trace request to any upstream LSP peer, it should immediately respond with a back-trace reply message with its own information. This information must state that this node is not a true ingress for the FEC received in back- trace message. This is informed through ingress flags TLV in the back-trace reply message. For more details about the Ingress TLV see section `Ingress Flags TLV' Each node has to encode into the back-trace reply message a message Id TLV. The mapping between a back-trace request and a back-trace reply message is done based on the message id. Besides the message Id TLV, each node has to encode the information that was queried (bandwidth, merging info, Ingress or Non Ingress LSR, Aggregation info, etc.,). After the encoding is done, the back-trace reply message is sent back, on the reversed path, towards the egress. Every LSR along the LSP tree has to encode its information according to what query flags are set. The back-trace response must follow the exact reverse path and the same LSP level traversed by back-trace message. 7. TLVs 7.1. Query TLV extensions. The Query TLV travels in the back-trace message till it reaches the Ingress or a node, which cannot forward the back-trace message further upstream. It then gets copied into a reverse flowing back- trace reply message and is used by ingress and intermediate LSRs to know what information is being queried in the back-trace. The following section describes the extensions to the Query TLV introduced in [QUERY]. Flags Q3, Q8 are never used in back-trace message. If they are set, they must be ignored by the LSRs along the LSP-Tree. For the purpose of collecting allocated bandwidth and ingress information in the LSP- Tree, we introduce two new flags Q4 and Q7. (Q4 and Q7 are reserved flags in [QUERY]). - Q4: Query the bandwidth; if set, the LSR that receives the back- trace message has to encode the bandwidth allocated over the outbound link for the LSP. - Q5: Query FEC aggregation information. See `Aggregation TLV' section. - Q7: Query which LSRs in the LSP-Tree act as Ingresses for the FEC received in back-trace message. 7.2. Tree TLV LSP Backtrace using MPLS-LDP/CR-LDP February 2002 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| Tree TLV (TBA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AddressFamily| IP Address .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sibling Count| Sub - Tree 1 ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub - Tree 2... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value field of tree TLV is a recursive structure capturing a tree. Each LSR (Root) IP address is followed by the sibling count. Root IP Address is the IP V4/V6 address of the root node. The LSPs out-bound port IP address is encoded as the Root IP address in the TLV. Sibling count follows the IP address of the root node. Sibling count indicates the total no of sub-trees following the present (sub) tree root. Sibling count is 8- bit value with range 0-255. Value 255 is reserved. It is used to inform that the LSR is not willing to reveal the sibling count. Sub-tree structure follows the sibling count field. The leaf nodes in the tree will have ZERO sibling count. The leaf nodes are most likely the Ingress points of the LSP. Whether the LSR is True ingress or not can be found from the Ingress flags TLV. The details of Ingress TLV are present in the following section. 7.3. Ingress Flags TLV The format for the Ingress Flags 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| Ingress Flags TLV(TBA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of LSRS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress flags | | | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ingress Flags TLV has 4 bytes field to store the number of LSRs in the LSP tree. This number is same as the number of LSRs, which are encoded in the Tree TLV. Each 2 bits in the ingress flags field represent the Ingress information for an LSR. The bits are set to 01 if the LSR is true Ingress for the back-traced LSP and are set to 10 otherwise. If the LSR wants to hide the ingress information, it has to set the Ingress flags to 00. The length of the encoding is rounded up to the next byte. Every LSR has to update the Number of LSRs field and set its corresponding bits accordingly. The ingress LSP Backtrace using MPLS-LDP/CR-LDP February 2002 information is encoded in the same order as the nodes in the tree TLV. LSP Backtrace using MPLS-LDP/CR-LDP February 2002 7.4. Reserved Bandwidth 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| TBA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |HOLDINGPRIORITY| Bandwidth Allocated ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ |Addr family |IP addr of interface (near end)~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP address of interface (far end) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LSP ID LSP ID of the back-traced CR-LSP. Holding Priority Holding priority of the CR-LSP Bandwidth Allocated Bandwidth allocated over the out-bound link of the CR-LSP in bytes per second. Address Family Address family of the following two IP addresses in the TLV. Finally the interface's IP address and far ends address are placed in the TLV. For example if the first address is A (near end) and the second address is B (far end), the bandwidth is reserved in the A to B direction. The LSRs along the LSP tree append their reserved bandwidth information to the back-trace reply message. The elements of this vector are encoded in the same order as the nodes in the tree TLV. For example assume that the tree TLV {R1, 2, S1, 0, S2, 0} has the reserved bandwidth vector {10, 100}. This indicates that 10 is the bandwidth unit reserved on link between R1 and S1, 100 is the bandwidth unit reserved on the link between R1 and S2. The IP addresses on each side of the link and hold priority of the LSP can be obtained by decoding individual elements of the received bandwidth vector. Optional Parameters: No optional parameters are defined at present. LSP Backtrace using MPLS-LDP/CR-LDP February 2002 7.5. Aggregation TLV The encoding for aggregation 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| TBA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of LSRs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aggregation Element 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aggregation Element 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aggregation Element n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The aggregation TLV is a list of aggregation elements. The order of the FEC elements corresponds to the order of LSRs in tree TLV. The aggregation TLV has 4 bytes field to store the number of LSRs in the LSP tree. This number is same as the number of LSRs, which are encoded in the Tree TLV. The length of this TLV encoding is rounded up to the next byte. Aggregation element is encoded as below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | FEC element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ First two bits in aggregate element represent the aggregation information for an LSR. The bits are set to 01 if the LSR is performing aggregation and are set to 10 otherwise. If the LSR wants to hide the aggregation information, it has to set these bits to 00. These two bits are followed by FEC element. FEC element will not be present if the aggregation bits are set to 10 or 00. 8. Notification message Handling When a notification message with status "No LSP to back-trace" is received from a LSP peer, as response to the back-trace message, the LSR has to stop waiting for a back-trace reply from that peer LSR. Status code summary Status Code E Status Data Section Title No LSP to back-trace 1 TBA "Back-trace Message procedures" LSP Backtrace using MPLS-LDP/CR-LDP February 2002 9. References [MPLS] Rosen E., Viswanathan A., "Multiprotocl Label Switching Architecture", RFC3031, January 2001. [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-03.txt, October 1999 (Work in progress) [LDP] Andersson et al., "LDP Specification", RFC3036, January 2001. [QUERY] Peter Ashwood-Smith et al.,"MPLS LDP Query Message description", draft-ietf-mpls-lsp-query-03.txt, August 2001. (Work in progress) [LDP-STATE] Christophe Boscher et al.,"LDP State Machine", draft- ietf-mpls-ldp-state-04.txt", March 2000 (Work in Progress) [OPTICAL] Ashwood-Smith P., Berger L., "Generalized MPLS-Signaling Functional Description", draft-ashwood-generalized-mpls-signaling- 00.txt (Work in progress) [TOPLOGY] Ashwood-Smith P., Bilel., "Improving Topology Data Base Accuracy with LSP Feed Back", draft-ietf-mpls-te-feed-02.txt, July 2001. (Work in progress) 10. Author's Addresses HariKishan Desineni, Ericsson, 70, Castilian Drive, SantaBarbara, California, USA - 93117 Phone: 1-805-252-2641 Email: harikishan.desineni@ericsson.com Kameswara Rao Avasarala, Ericsson, 70,Castlian Drive, SantaBarbara, California, USA-93117 Phone: 1-805-562-6212 Email: kameswara.rao@ericsson.com