Internet Draft Harikishan Desineni Document:draft-kishan-lsp-btrace-02.txt Kameswararao Avasarala Expires: November 2002 Ericsson May 2002 Label Switched Path backtrace using Multi Protocol Label Switching Label Distribution Protocol/Constraint Based Label Distributed Protocol draft-kishan-lsp-btrace-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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This document describes the encoding and procedures for new Label Distribution Protocol (LDP) messages, the back trace message and back trace reply message. The back trace message is sent for an established Label Switched Path(LSP). The back trace message can be used for Label Distribution Protocol(LDP) Label Switched paths as well as for Constraint Based Label Switched Paths (CR-LSPs). The data requested is encoded into the back trace reply message. Backtrace mechanism described in this draft can be used for obtaining the MPLS Harikishan, et. al. [Page 1] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 topology information for a particular Forwarding Equivalence Class (FEC) in a Multi Protocol Label Switching (MPLS) domain. TABLE OF CONTENTS 1. Introduction...............................................2 2. Terminology ...............................................4 3. New Messages ..............................................5 4. LDP Message Structure Overview ............................5 5. Behavior of LSRs with constraints in handling the backtrace message ...................................................6 6. BackTrace Message .........................................8 6.1 BackTrace message encoding ................................8 6.2 BackTrace Message procedures...............................9 7. Backtrace Reply Message ..................................10 7.1 Backtrace Reply message encoding .........................10 7.2 BackTrace Reply Message Procedures .......................12 8. TLVs .....................................................13 8.1 Query TLV extensions .....................................13 8.2 Tree TLV .................................................14 8.3 Ingress Flags TLV ........................................14 8.4 Reserved Bandwidth TLV ...................................15 8.5 Aggregation TLV ..........................................16 8.6 Notification message Handling ............................17 9 Security Considerations...................................17 10 IANA Considerations.......................................17 11 Normative References......................................18 12 Author'sAddresses.........................................18 1. Introduction This draft describes the backtrace mechanism for an LSP or CR-LSP. It specifies procedures and encoding for the new messages added for the backtrace mechanism. Extensions to RSVP-TE to provide the same functionality are subject for future study and will be covered in future draft versions. Backtrace mechanism described in this draft can be used for obtaining the MPLS topology information for a particular Forwarding Equivalence Class (FEC) in a MPLS domain. The following example describes the way backtracing mechanism works. Harikishan, et. al. [Page 2] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 Consider a MPLS domain with six nodes and six links captured as a graph in the below shown diagram. [R2] |f | [R5] a / \e / \ [R1]---[R4] \ / b \ /d [R6] |c | [R3] Nodes R1,R2,R3 and R4 are the edge Label Switched Routers of the MPLS domain. Let,R4 be the egress for Forwarding Equivalence Class "F". Assume that there exists following LSPs in the MPLS domain for the Forwarding Equivalence Class (FEC) "F". Assume that R5,R6 are merge capable. LSP for Forwarding Equivalence Class "F" from R1 to R4 is L1 = {R1,a,R5,e,R4} LSP for Forwarding Equivalence Class "F" from R2 to R4 is L2 = {R2,f,R5,e,R4} LSP for Forwarding Equivalence Class "F" from R3 to R4 is L3 = {R3,c,R6,d,R4} R5 has merged L1 and L2.Triggering LSP backtrace from R4 should result in the following LSP tree rooted at R4. [R1] \a \ [R5] / \e /f \ [R2] [R4] / / d / [R6] / /c [R3] To perform the construction of LSP tree, we introduce LSP back trace and backtrace reply messages in MPLS-LDP. The egress Label Switched Router R4 sends backtrace messages to R6 and R5.Label Switched Router Harikishan, et. al. [Page 3] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 R5 in turn propagates the backtrace message to R1 and R2.At R6,the backtrace message is propagated to R3. As R1,R2 and R3 are ingresses for Forwarding Equivalence Class (FEC) "F", they respond with backtrace reply message. The backtrace reply message from each Label Switched Router includes the sub tree originating from it, representing the set of LSPs merging at it for Forwarding Equivalence Class (FEC) "F". R5 collects the backtrace replies from Label Switched Router 1, Label Switched Router 2, appends its own information, builds the new sub tree with root being it self and sends new backtrace response to R4. R6 receives the backtrace response from R3,appends its own information, builds the new sub tree with root being it self and sends a new backtrace response to R4. R4 collets the sub trees in the backtrace replies from R5,R6 and builds the complete LSP Tree for Forwarding Equivalence Class "F" with root being it self. The above mechanism builds LSP tree rooted at an Label Switched Router acting as egress for an Forwarding Equivalence Class (FEC) in the MPLS domain. It is also possible to append additional information to the LSP backtrace message at each Label Switched Router. Additional information could include details such as bandwidth allocated for the LSP over the particular link, amount of unreserved bandwidth on the link, labels used along the LSP, merging capabilities of the Label Switched Router (VP, VC, VP and VC merges in case of MPLS over ATM), availability of label resources and any other type of information which can be useful for MPLS network management. Though the egress Label Switched Router is treated as a node of choice for triggering the LSP Backtrace, this mechanism can also be performed from any node acting as intermediate Label Switched Router for a Forwarding Equivalence Class. LSP backtrace should be able to obtain as much information as possible from the Label Switched Routers in the MPLS domain. If a Label Switched Router cannot propagate the backtrace message upstream, it may respond with a backtrace reply message with additional information stating that it is not an ingress for the Forwarding Equivalence Class. Some Label Switched Routers may act as both intermediate and ingress Label Switched Router for a Forwarding Equivalence Class. The backtrace response message traverses the exact reverse path of the backtrace message and collects information at the same LSP level traversed by backtrace message. Backtracing LSPs at a level different from the level at which the backtrace message is issued is a subject for further study and is beyond the scope of this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. This section gives a general conceptual overview of the terms used in this document. Some of these terms are more precisely defined in later sections of the document. Harikishan, et. al. [Page 4] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 LSP Backtrace A method to identify the label switched paths at one level of the hierarchy followed by packets in a particular Forwarding Equivalence Class. TRUE Ingress Label Switched Router An Label Switched Router which acts only as an Ingress Label Switched Router for a Forwarding Equivalence Class and is not acting as intermediate Label Switched Router for the same Forwarding Equivalence Class. 3. New Messages The new LDP messages introduced for supporting backtrace are backtrace message and backtrace reply message.The following new TLVs are added to accommodate the encoding for the backtrace and backtrace reply 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 backtrace mechanism, are sent over TCP as well. 4. 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. Harikishan, et. al. [Page 5] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Mandatory Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. Used by the sending Label Switched Router to facilitate identifying notification messages that may apply to this message. An Label Switched Router 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. 5. Behavior of Label Switched Routers with constraints in handling the backtrace message Upon receiving a backtrace message, an Label Switched Router has to behave according to its configuration constraints in handling the Harikishan, et. al. [Page 6] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 backtrace message and returning the queried information. The following cases were identified: - The Label Switched Router does not support the code to handle the messages for the backtrace mechanism. In this case, the Label Switched Router has to behave as if it received an unknown message type. It has therefore to honor the U bit. - The Label Switched Router supports the code to handle the messages for the backtrace mechanism, but it is configured not to return any data. In this case, the Label Switched Router is able to decode and process the backtrace messages. However, it is configured to hide all the data. It should not propagate the message to the upstream LSP peers. It may respond with a backtrace reply message. - The Label Switched Router supports the code to handle the messages for the backtrace mechanism, but it is configured not to return part of the queried data. In this case, the Label Switched Router is able to decode and process the backtrace messages. It has to propagate the backtrace reply message. 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 Label Switched Router is configured to hide its sibling information(Information about upstream Label Switched Routers for the given Forwarding Equivalence Class), it has to encode sibling count (Number of upstream Label Switched Routers for the given Forwarding Equivalence Class as 255 in Tree TLV. For more information on Tree TLV, see the section on "Tree TLV". For more information on true ingress information see the section "Ingress Flags TLV". For more information about ingress flags information see section "Ingress Flags TLV". - The Label Switched Router supports the code to handle the messages for the backtrace mechanism, and it is configured to return all the data, which is queried. This is the normal case for an Label Switched Router. In this case, the behavior of Label Switched Router has to follow the backtrace and backtrace reply procedures described in the following sections. The decision that an Label Switched Router can share the backtrace information has to be controlled through local configuration. Harikishan, et. al. [Page 7] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 6. BackTrace Message This section describes the backtrace message and its encoding and procedures. This message is meant to gather information about an LSP tree for a Forwarding Equivalence Class. It can be sent at any time for an established LSP. The backtrace message can be used to gather information about: - Label Switched Routers, which form the LSP-Tree of a Forwarding Equivalence Class(FEC). - Labels used along the LSP-Tree. - Information about which Label Switched Routers are merging points in the LSP tree. - Reserved bandwidth 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 Forwarding Equivalence Class aggregation occurring at Label Switched Routers in the LSP-Tree. - Anything that is needed in future for MPLS network management, which can be computed and encoded in a TLV. The backtrace information is encoded in the backtrace reply message, which is sent back downstream, as a response to the backtrace message. 6.1 BackTrace message encoding The encoding for the backtrace 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| BackTrace Type TBD IANA | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Count TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. Harikishan, et. al. [Page 8] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 FEC TLV The FEC TLV must include only one Forwarding Equivalence Class element corresponding to the Forwarding Equivalence Class being backtraced. 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 Label Switched Router 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 Label Switched Router that receives the backtrace message has to subtract one 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. 6.2 BackTrace Message Procedures The Label Switched Router Egress initiates the backtrace message. It populates the Query TLV Parameters according to what kind of information it wants to gather. Backtrace for a LSP is done by its Forwarding Equivalence Class. Upon receiving a backtrace Message, an Label Switched Router decodes the Forwarding Equivalence Class and finds the outgoing label to identify the LSP is being backtraced. If it cannot find the LSP, it sends back a Notification message with "No LSP to backtrace" status. Otherwise, it finds the incoming set of labels, which are merged into the already found outgoing label. Then the Label Switched Router computes the upstream Label Switched Router peer set "S", containing a LDP peer corresponding to each incoming label in the incoming label set. Then it computes another set "P", which is a subset of "S" containing only the upstream Label Switched Routers, which were advertised a label binding for a Forwarding Equivalence Class, which in turn either subsumes the Forwarding Equivalence Class received in the backtrace message or is subsumed by the Forwarding Equivalence Class in the backtrace message. After computing the upstream Label Switched Router peer set "P", the Label Switched Router propagates the backtrace 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 backtrace request to the same member of the set "P". This situation arises when a Label Switched Router advertises several Forwarding Equivalence Class-Label bindings to an upstream peer, where each of the advertised Forwarding Equivalence Classes may either subsume or be subsumed by the Harikishan, et. al. [Page 9] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 Forwarding Equivalence Class received in backtrace request. A mechanism to find the upstream peer for an incoming label can be found in [LDP-STATE]. When the backtrace request message gets to a tunnel, it has to be propagated to the upstream LSP peer at the same LSP level. I.e., the backtrace 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 backtrace message, the ingress Label Switched Router has to respond with a backtrace reply message. The backtrace reply message contains the Query TLV, which was received in the backtrace message. The Query TLV tells the Label Switched Routers along the path which information is being queried and allows intermediate Label Switched Routers to piggy back their own queried information on the backtrace reply message. 7. Backtrace Reply Message This message is propagated downstream. It is sent in response to a backtrace request message. The egress, which initiated the backtrace message, is interested in gathering information from all the nodes in the LSP tree for the Forwarding Equivalence Class. However, there are situations in which the backtrace message does not reach all the ingress Label Switched Routers for the Forwarding Equivalence Class being backtraced. In these scenarios it would be useful if the egress Label Switched Router gathered at least some information about the Label Switched Routers, which are along the path, up to the one that failed. If the backtrace reply message is full, TCP will take care of it by segmenting and reassembling the message. Backtrace reply message is described in the following sections. 7.1 Backtrace reply message encoding This message can be generated by any Label Switched Router along the LSP-Tree. It is sent downstream, by each Label Switched Router along the path. The encoding for the backtrace reply message is: Harikishan, et. al. [Page 10] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 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 Type TBD IANA| 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] for TLV 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] Query Merge Flags TLV var See [QUERY] Ingress Flags TLV var See Section 8.3 Reserved Bandwidth TLV var See Section 8.4 Aggregation TLV var See Section 8.5 For simplicity we reuse here TLV types defined in [CR- LDP],[LDP],[QUERY] and [OPTICAL]. They are: - 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 Label Switched Router along the LSP-Tree. Its length is rounded up to the next byte. If Q7 is set in Query TLV, every Label Switched Router along the path Harikishan, et. al. [Page 11] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 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 Q5 is set in Query TLV, every Label Switched Router along the LSP-Tree will have to fill this information, if it is configured to reveal such information. If an Label Switched Router 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 Forwarding Equivalence Class aggregation occurring along the paths in the LSP-Tree. If Q6 flag is set in Query TLV, every Label Switched Router along the LSP-Tree will have to fill this information, if it is configured to reveal such information. If the Label Switched Router is performing Forwarding Equivalence Class aggregation, the encoded information includes a Forwarding Equivalence Class, which is either subsumes or subsumed by the Forwarding Equivalence Class being backtraced. For more information on this TLV, see section "Aggregation TLV". The information encoded in the above TLVs s by each Label Switched Router, 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],[LDP],[OPTICAL] and [QUERY]. 7.2 BackTrace Reply Message Procedures A BackTrace reply message can be generated by any node, which receives a backtrace request message, if the node is able to identify an LSP for the Forwarding Equivalence Class received. If the node is not able to identify the Forwarding Equivalence Class, it replies with a notification message with "No LSP to backtrace" status. If the node is true ingress of the LSP, it can immediately send the backtrace reply to the downstream LSP peer. If the node is not the ingress of the LSP, it waits for the responses from Label Switched Routers in the upstream LSP peer (siblings) set "P", computed as described in section 6.2. The timeout period for the responses from upstream LSP peers is implementation dependent and should be locally configurable. Once the timeout period expires, the node should generate a backtrace reply with whatever information it has gathered from the upstream LSP peers that have responded within the timeout interval. The gathered LSP sub-tree information is encoded as tree TLV in backtrace reply message. Responses received after timeout interval should be ignored. If the node is not able to propagate the backtrace request to any upstream LSP peer, it should immediately respond with a backtrace Harikishan, et. al. [Page 12] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 reply message with its own information. This information must state that this node is not a true ingress for the Forwarding Equivalence Class received in backtrace message. This is informed through ingress flags TLV in the backtrace reply message. For more details about the Ingress TLV see section "Ingress Flags TLV". Each node has to encode into the backtrace reply message a message Id TLV. The mapping between a backtrace request and a backtrace 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 Label Switched Router, Aggregation info, etc.,). After the encoding is done, the backtrace reply message is sent back on the reverse path, towards the egress. Every Label Switched Router along the LSP tree has to encode its information according to what query flags are set. The backtrace response must follow the exact reverse path and the same LSP level traversed by backtrace message. 8. TLVs 8.1 Query TLV extensions. The Query TLV travels in the backtrace message till it reaches the ingress or a node, which cannot forward the backtrace message further upstream. It then gets copied into a reverse flowing backtrace reply message and is used by ingress and intermediate Label Switched Routers to know what information is being queried in the backtrace. The following section describes the extensions to the Query TLV introduced in [QUERY]. For the purpose of collecting allocated bandwidth and ingress information in the LSP-Tree, we introduce two new flags Q5 and Q7. Flag Q6 is introduced to collect Forwarding Equivalence Class aggregation information. Q5,Q6 and Q7 are reserved flags in [QUERY]. - Q5: Query the bandwidth; if set, the Label Switched Router that receives the backtrace message has to encode the bandwidth allocated over the outbound link for the LSP. - Q6: Query Forwarding Equivalence Class aggregation information. See "Aggregation TLV" section. - Q7: Query which Label Switched Routers in the LSP-Tree act as Ingresses for the Forwarding Equivalence Class received in backtrace message. Harikishan, et. al. [Page 13] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 8.2 Tree 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|0| Tree TLV Type TBD IANA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | IP Address .... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sibling Count | SubûTree 1 .... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Tree 2 ...... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value field of tree TLV is a recursive structure capturing a tree. Each Label Switched Router (Root)IP address is followed by the sibling count. Root IP Address is the IP V4/V6 address of the root node. The LSPs outbound 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 Label Switched Router is not willing to reveal the sibling count. Sub-tree structure follows the sibling count field. The tree structure is encoded in depth first order. The leaf nodes in the tree will have ZERO sibling count. The leaf nodes are most likely the Ingress Label Switched Routers of the LSP. Whether the Label Switched Router is True ingress or not can be found from the Ingress flags TLV. The details of Ingress TLV are present in the following section. 8.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 TBD IANA| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of LSRS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress flags | | | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ingress Flags TLV has 4 bytes field to store the number of Label Switched Routers in the LSP tree. This number is same as the number Harikishan, et. al. [Page 14] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 of Label Switched Routers, which are encoded in the Tree TLV. Each 2 bits in the ingress flags field represent the Ingress information for an Label Switched Router. The bits are set to 01 if the Label Switched Router is true Ingress for the backtraced LSP and are set to 10 otherwise. It is set to 11 if the Label Switched Router can act as both ingress and intermediate Label Switched Router for the Forwarding Equivalence Class. If the Label Switched Router 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 Label Switched Router has to update the Number of Label Switched Routers field and set its corresponding bits accordingly. The ingress information is encoded in the same order as the nodes in the tree TLV. 8.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|Rsvd Bandwidth TLV TBD IANA| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |HOLDINGPRIORITY| Bandwidth Allocated (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Address family |IP addr of +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interface (near end) ..... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP address of interface (far end) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LSP ID LSP ID of the backtraced 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. Harikishan, et. al. [Page 15] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 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 Label Switched Routers along the LSP tree append their reserved bandwidth information to the backtrace 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. 8.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| Aggregation TLV TBD IANA | 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 Forwarding Equivalence Class elements corresponds to the order of Label Switched Routers in tree TLV. The aggregation TLV has 4 bytes field to store the number of Label Switched Routers in the LSP tree. This number is same as the number of Label Switched Routers, which are encoded in the Tree TLV. The length of this TLV encoding is rounded up to the next byte. Harikishan, et. al. [Page 16] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 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 Label Switched Router. The bits are set to 01 if the Label Switched Router is performing aggregation and are set to 10 otherwise. If the Label Switched Router wants to hide the aggregation information, it has to set these bits to 00. These two bits are followed by Forwarding Equivalence Class element. Forwarding Equivalence Class element will not be present if the aggregation bits are set to 10 or 00. 8.6 Notification message Handling When a notification message with status ôNo LSP to backtraceö is received from a LSP peer, as response to the backtrace message, the Label Switched Router has to stop waiting for a backtrace reply from that peer Label Switched Router. Status code summary Status Code E Status Data Section Title No LSP to backtrace 1 TBD IANA "Backtrace Message procedures.." 9. Security Considerations The backtrace mechanism inherits the same security mechanism described in Section 5.0 of [LDP]. The backtrace mechanism provides an additional security measure for cases when a node cannot share the information being queried by backtrace message. Such nodes have the option of hiding their information, if their configuration requires it. Please refer to Section 5 of this draft - "Behavior of Label Switched Routers with constraints in handling the backtrace message" for more details. 10. IANA Considerations The backtrace mechanism does not require a new message type space, a TLV type space or a Status code space. Extensions to the LDP spaces are required, as follows: Harikishan, et. al. [Page 17] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 - the message types for backtrace Message, backtrace reply message should be provided by extending the LDP message type space. - the TLV types for Tree TLV, Ingress Flags TLV, Reserved Bandwidth TLV and Aggregation TLV should be provided by extending the LDP TLV type space. - the Status code "No LSP to backtrace" should be provided by extending the LDP Status code space. 11. Normative References [MPLS] Rosen E., Viswanathan A., "Multiprotocl Label Switching Architecture", RFC3031, January 2001. [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", RFC3212, January 2002. [LDP] Andersson et al., "LDP Specification",RFC3036, January 2001. [QUERY] Peter Ashwood-Smith et al.,"MPLS LDP Query Message description", Work in Progress, draft-ietf-mpls-lsp-query-04.txt. [LDP-STATE] Christophe Boscher et al.,"LDP State Machine",RFC3215, January 2002 [OPTICAL] Ashwood-Smith P., Berger L., "Generalized MPLS-Signaling Functional Description", draft-ietf-mpls-generalized-mpls-signaling- 07.txt, November 2001,Work in progress. 12. Author's Addresses Harikishan Desineni Ericsson 70,Castiian Drive Santa Barbara California USA-93117 Tel: +1 805 562 6419 Mobile: +1 805 252 2641 Email: desineni@hotmail.com KameswaraRao Avasarala Ericsson 70,Castlian Drive Santa Barbara California USA-93117 Harikishan, et. al. [Page 18] Internet Draft LSP Back trace using MPLS-LDP/CR-LDP May 2002 Phone: +1 805 562 6212 Email: kameswara.rao@ericsson.com Harikishan, et. al. [Page 19]