MPLS Working Group Heinrich Hummel Internet Draft Siemens AG Expiration Date: August 1999 Swee Loke Nortel Networks Febuary 1999 Explicit Tree Routing draft-hummel-mpls-explicit-tree-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 except that the right to produce derivative works is not granted. 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 draft proposes the TREE ROUTE TLV that encodes a tree structured route which can be used to carry explicit routing information. It also specifies the progression of the TLV from the root of the tree to the leaf nodes. Every node that the TLV traversed has to decode/process the TLV in such a way that the correct child link/ nodes are determined as well as the respective subtree route information. Individual Information targetted for any specific node can also be packed into this TREE ROUTE TLV. The draft also presents the benefits of using TREE ROUTE TLV in MPLS. Hummel & Loke Febuary 1999 [Page 1] Explicit Tree Routing Exp. Aug 1999 The applications include constrain based routing, traffic engineering, VPN installations and static multicast tree. The capability of carrying targetted information for individual node in the tree is very powerful in MPLS. This allows different nodes in the tree route to use the same tree route for different FECs. The application of this TLV is not mpls-specific. Other Working Groups may consider the proposed TLV as well. 1. Introduction It is agreed that explicit routing is needed in MPLS. Different TLVs and protocols have been designed or enhanced to support explicit routing. Most of the work has been focused on point-to-point LSPs. This draft proposes the TREE ROUTE TLV which can encode a tree structured route. The tree structured route may be provided based on some static configuration information or derived algorithmically from the results of a dynamic route computation. The decision is up to the protocols that use the TLV, and is outside the scope of this draft. The TREE ROUTE TLV can be used in some LSP setup protocol (E.g., LDP with possibly some new message types) to setup explicit point-to- multipoint and multipoint-to-point LSPs. The exact specification of supporting TREE ROUTE TLV in the LSP setup protocol is for further study and is outside the scope of this draft. Section 2 presents different applications of the TREE ROUTE TLV in MPLS and their benefits. The TREE ROUTE TLV is independent of its application. It guides the message/packet to each leaf properly, but besides that, it has no indication of any application-dependent actions to be taken on the way to the leaves. Instead, to give such instructions, that should be the job of the protocol message (e.g., LDP message) that carries the TREE ROUTE TLV (or of any other TLV). Consequently, the TREE ROUTE TLV can be used for MPLS and NON-MPLS applications. Section 3 specifies the TREE ROUTE TLV. The progression of the TLV from the root to the leaf nodes are specified in section 4. When all intermediate routers process the received TREE ROUTE TLV using the same processing algorithm, the TREE ROUTE TLV will be forwarded exactly along the tree route as indicated by the TLV. When the TLV reaches a leave node, the FEC TLV targetted for the leaf node shall be processed as required. Section 5 presents ways to compress the tree route TLV. Appendix A shows the TREE ROUTE TLV encoding algorithm. Appendix B shows the Hummel & Loke Febuary 1999 [Page 2] Explicit Tree Routing Exp. Aug 1999 decoding algorithm to be performed by each transit node. 2. Applications and Benefits The TREE ROUTE TLV can be used to setup different types of MPLS LSPs. The following subsections presents different MPLS applications of the TREE ROUTE TLV and their benefits. 2.1 Egress-rooted Label Switch Tree (ELST) ELST refers to a multipoint-to-point LSP triggered by the Egress LER. This type of Label Switch Tree (LST) is very useful for traffic engineering and VPN configuration. The benefits: - The ELST setup info only needs to to be configured at one node, namely the Egress node. This saves having to configure multiple point-to-point LSRs from the Ingress nodes to Egress. By establishing a multipoint-to-point LST explicitly, we can specify where the merge points are and have more control on the traffic flow. - Since information targetted for each leaf node can be packed into this TREE ROUTE TLV, the leaf nodes (ingress and intermediate routers) can use the same tree for different FECs. Once data traffic enters the ELST, it will be forwarded to the root, regardless what the FEC is. By defining the FEC(s) for the tree route on each node, it allows other point-to-point LSPs of that FEC to join the tree. - The LST will not be triggered if the Egress node is down. In the existing ER LSP, the Ingress node will always try to set up the ER LSP by sending the label request regardless if the Egress is up. Hummel & Loke Febuary 1999 [Page 3] Explicit Tree Routing Exp. Aug 1999 2.2 Ingress-rooted Label Switch Tree (ILST) ILST refers to a point-to-multipoint LSP setup by the Ingress LER. This type of Label Switch Tree (LST) is useful for static multicast tree and VPN. The benefits: - All the same benefits as existing point-to-point ER LSP - The ILST setup info only needs to be configured at one node, namely the Ingress node. This saves having to configure multiple point-to-point LSPs from the Ingress to multiple Egress nodes. - The static tree can be used to deliver multicast traffic across different multicast routing domain. Each leaf node of the LST can be the root of its own multicast tree. The tree can allow dynamic branches by allowing other LSP of the same FEC to merge/join to the tree. The extending/pruning of the LST is for future study. - The point-to-multipoint LST can be used to deliver broadcast type messages to VPN LAN that is emulated across the MPLS backbone. 2.3 Others The TREE ROUTE TLV is also efficient for a tree route that is linear (i.e., a never branching route). There is no extra overhead if it is used to specify a linear point-to-point LSP. Multiple linear LSPs towards the same Egress node can be merged and described with one TREE ROUTE TLV. The following figure shows an example of such LSPs: +-----+ L1 +----+ L2 +----+ L3 +----+ |R0=3D |<---|R1=3D |<----|R2=3D |<-----|R3=3D | |Root | |Leaf| |Leaf| |Leaf| +-----+ +----+ +----+ +----+ R1 uses R2 uses R3 uses it for it for it for FEC-1 FEC-2 FEC-3 Hummel & Loke Febuary 1999 [Page 4] Explicit Tree Routing Exp. Aug 1999 In this example, R2 uses the linear route (R1,R0) for traffic with FEC-2. At the same time, it also forwards the traffic enterring the LSP from R3. Only one label at each node is required to set up the LSP that carries all traffic flow towards R0. Multiple LSPs of different FECs are implicitly merged. The benefits: - All the same benefits as exisiting point-to-point ER LSP - It is more efficient to set up the LSP this way than setting up multiple mergable point-to-point ER LSPs. - Scalability: Only one lable is required at each node. - It allows the linear point-to-point LSP to grow into a tree as the merge points of different FECs are specified. 3. TREE ROUTE TLV Specification This section presents the definition of a tree route and the notation of a TREE ROUTE TLV. 3.1 Tree Route Definition A TREE ROUTE TLV can encode an explicit routing tree that consists of the following types of nodes: - Root node A root node is the node where the initial TREE ROUTE TLV is generated. It is also where the data traffic enters the tree route (in point-to-multipoint case) or where the data traffic terminates (in multipoint-to-point case). There is only one root node per tree. - Transit Node A Transit node is a node that is responsible for forwarding the data traffic along the tree route. Every node in a tree route, except the root node and the pure leaf nodes, is a transit node. - Leaf Node Hummel & Loke Febuary 1999 [Page 5] Explicit Tree Routing Exp. Aug 1999 A leaf node is a node + which is to receive data traffic sent to the tree route from the root (in point-to-multipoint case), OR + where the data traffic to be delivered to the root enters the tree route (in multipoint-to-point case) For example, a leaf node in the point-to-multipoint multicast tree is a node that is to receive the traffic from the root, whereas a leaf node in a multipoint-to-point tree acts as an Ingress node for data traffic sent towards the root. A leaf node can be also a transit node. Hence, in the point-to-multipoint case, a leaf node that is also a transit node receives the data traffic itself and also forwards the data traffic along the tree route. 3.2 TREE ROUTE TLV Notation The TREE ROUTE TLV contains a sequence of TLVs of the following types: - TYPE "(" - TYPE ")" - TYPE "Linear Sequence of Hops" - TYPE "FEC" The "("-TLVs and the ")"-TLVs have no associated values and have type length of zero, as they are used mainly to shape the tree. The "Linear Sequence of Hops"-TLV contains one or more hops that form a linear section of the tree route. It also contains a Hop type which indicates the uniform way how all containing hops are encoded. For example, the hop type of a "Linear Sequence of Hop"-TLV = can indicate that all hops are provided by IPv4 router IDs or IPv4 = interface addresses. Other hop types are envisioned as well but are = for further study: autonomous system numbers, tunnel ids, IDs for = ATM-SVCs, Frame Relay DLCIs and LSP IDs. The FEC-TLV contains the target information for an individual leaf = node. It will be embraced by a "("- and ")"-TLV pair, Hummel & Loke Febuary 1999 [Page 6] Explicit Tree Routing Exp. Aug 1999 positioned such that it can be associated with the respective leaf node. Indeed, the last hop of the preceding "Linear Sequence of Hops"-TLV will either denote the respective leaf node itself or the link to the respective leaf node. In all examples presented in this draft, the following notations will be used to represent the different TLVs that comprise the TREE ROUTE TLV: [...] represents a TLV of Type "Linear Sequence of Hops" where the hop type is router-id. Each hop is separated by a period. ) represents a ")"-TLV ( represents a "("-TLV FEC-j indicates an individual FEC-TLV for node j. It may be present only if applicable. Each TLV notation are shown separated by a comma. General rules of how to encode the tree route information: - The first contained TLV is always a "Linear Sequence of Hops"-TLV whose first hop either points to the next receiving node or denotes the link to the next receiving node. - A node is marked to be a leaf node by placing either "(", ")" or "(", FEC, ")" behind that "Linear Sequence of Hops"-TLV whose last hop either denotes this node or denotes the link to this node. - Each entire subtree route following a branching node is embraced with "(" and ")". Here is an example of how to encode a simple tree where no FEC is associated with any node. R0 is the root, R2, R3, R4 are the leaf nodes. +-----+ +----+ +----+ |R0=3D |----|R1 |--+--|R2=3D | |Root | | | | |Leaf| +-----+ +----+ | +----+ | | +----+ +----+ +--|R3=3D |----|R4=3D | |Leaf| |Leaf| +----+ +----+ Hummel & Loke Febuary 1999 [Page 7] Explicit Tree Routing Exp. Aug 1999 The initial TREE ROUTE TLV generated by the root node R0 is: [R1],(,[R2],(,),) (,[R3],(,),[R4],(,),) Here is the initial TREE ROUTE TLV sent by R0 to R1 in the simple example in section 2.3: [R1],(,FEC-1,),[R2],(,FEC-2,),[R3],(,FEC-3,) Appendix A shows how an initial TREE ROUTE TLV can be derived algorithmically based on some tree specification. 4. The Progressiong of TREE ROUTE TLV This section shows an example of a tree and how the corresponding TREE ROUTE TLV looks like at the beginning. It then shows how each transit node determines the child links and child TLVs. Any node that receives a TREE ROUTE TLV must apply the same decoding algorithm in order to determine its immediate child links and the respective TREE ROUTE TLVs to be sent down these links. A transit node will also determine if it is a leaf node as well. A leaf node may receive an individual FEC TLV that has to be evaluated only by itself and not to be propagated further. The following figure shows a tree of nodes Ri and links Lj. A setup message needs to be sent from router R1 (Root) to all nodes in the tree, and R3, R4, R5 and R7 are leaf nodes that have FEC-3, FEC-4, FEC-5, and FEC-7 targetted for them respectively. +----+ L2 +---+ L3 +----+ L4 +----+ L5 +----+ |R1=3D |-----|R2 |-----|R3=3D |-----|R4=3D |----|R5=3D | |Root| | | |Leaf| |Leaf| |Leaf| +----+ +---+ +----+ +----+ +----+ | |L6 +----+ +---+ L7 |R7=3D | |R6 |------|Leaf| +---+ +----+ Router R1 sends a message to Router R2, with a TREE ROUTE TLV that contains the following TLVs (shown separated by commas): Hummel & Loke Febuary 1999 [Page 8] Explicit Tree Routing Exp. Aug 1999 [R2.R3],(,FEC-3,),(,[R4],(,FEC-4,),[R5],(,FEC-5,),), (,[R6.R7],(,FEC-7,),) [...] represents a TLV of Type "Linear Sequence of Hops" where the hop type is router-id. The same example can also be illustrated using the link hop type. ) represents a ")"-TLV ( represents a "("-TLV FEC-j indicates an individual FEC-TLV for node j. R2 decodes the received TREE ROUTE TLV, and sends the following to R3:= [R3], (,FEC-3,),(,[R4],(,FEC-4,),[R5],(,FEC-5,),), (,[R6.R7],(,FEC-7,),) R3 recognizes itself being a leaf node, getting FEC-3. It also recognizes that it is a branching nodes and has to send the revised TREE ROUTE TLV to R4 and R6. R3 then sends to R4: [R4],(,FEC-4,),[R5],(,FEC-5,) R3 then sends to R6: [R6.R7],(,FEC-7,) R4 recognizes itself being a leaf node, getting FEC-4. R4 then sends to R5: [R5],(,FEC-5,) R5 recognizes itself being a leaf node, getting FEC-5. R6 sends to R7: [R7],(,FEC-7,) R7 recognizes itself being a leaf node, getting FEC-7. The algorithm of decoding the TREE ROUTE TLV is shown in Appendix B. 5. Compressing the TREE ROUTE TLV It is feasable to optimize the TREE ROUTE TLV and its processing. One possibility is to omit the "("-TLV and enhance the ")"-TLV with a number that indicates how many TLVs is needed to go back to get to the omitted complementary "("-TLV. Furthermore, any cluster of ")"-TLVs could be replaced by the single most right ")"-TLV of the cluster, enhanced with adjusted number. A ")"-TLV at the very end of the TREE ROUTE TLV can be omitted too. As a result the transmitted TREE ROUTE TLV became shorter and the (enhanced) decoding algorithm DA became faster. The exact compression of TREE ROUTE TLV is for further study. Hummel & Loke Febuary 1999 [Page 9] Explicit Tree Routing Exp. Aug 1999 6. Conclusion This draft proposes a generic TREE ROUTE TLV that can be used in different areas, inside and outside of MPLS. In MPLS, it can be used to establish LSPs for point-to-multipoint or multipoint-to-point flows. It is preferred that the TREE ROUTE TLV does not contain information that goes beyond the task of forwarding the message. Instead, the message itself and other TLVs should instruct the traversed nodes what to do additionally. The TREE ROUTE TLV works well also in case of linear routes. In fact it is a powerful way to carry an explicit route information that allows nodes along the linear path to use the route for different FECs without using additional labels. The application of this TLV is not mpls-specific. Other Working Groups (e.g. which are dealing with Multicast) may consider the proposed TLV as well. The specification of handling TREE ROUTE TLV in LSP setup protocols is for further study. 7. Intellectual Property Considerations Siemens AG and Nortel Networks may seek patent or other intellectual property protection for some or all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Siemens AG or Nortel Networks, Siemens AG and Nortel Networks intend to disclose those patents and license them under openly specified and non-discriminatory terms. 8. References [1] Rosen, Viswanathan, Callon: A Proposed Architecture for MPLS, (Work In Progress) Internet Draft, draft-ietf-mpls-arch-04.txt, Feb 1999. Hummel & Loke Febuary 1999 [Page 10] Explicit Tree Routing Exp. Aug 1999 9. Authors' Addresses Heinrich Hummel Siemens AG Hofmannstrasse 51 81379 Munich, Germany Tel: +49 89 722 32057 Email: heinrich.hummel@icn.siemens.de Swee Loke Nortel Networks P.O.Box 3511 Station C Ottawa ON K1Y 4H7 Canada Tel: (613) 763-9658 Email: loke@nortelnetworks.com Hummel & Loke Febuary 1999 [Page 11] = Explicit Tree Routing Exp. Aug 1999 APPENDIX A: Encoding Algorithm: Determining the initial child links and respective TREE ROUTE TLVs based on the results of a Dijkstra route computation. Although this example illustrates the encoding algorithm based on the result of Dijkstra route computation, it can be based on some tree specification= from configuration. Source node s may have done a Dijkstra route computation that provides= the shortest pathes to (at least) all those destination nodes d1, TREE ROUTE TLV. We presume that a Dijkstra route computation has returned for each node i its predecessor node p: P[i]=3Dp, whereby P[s]=3Ds. It is also assumed that all branches of the tree are removed that do not contribute to interlinking source node s and destination nodes d1,...,dr. I.e. by proper actions P[k] is set to 0 for all nodes k that do not contribute to this interlinkage. Based on the resulting vector P and by proper actions - which are not described here - we determine for each Transit Node i: - its parent link, i.e., TN[i].ParentLink (which is =3D P[i] ) - the number of its child links, i.e., TN[i].ChildLinkCount - and its child links themselves, i.e., TN[i].ChildLink[k] for k=3D1,...TN[i].ChildLinkCount We mark all leaf nodes k=3Dd1,...,dr: TN[k].IsLeaf :=3D TRUE ; and, if applicable, provide some of them with an individual FEC: TN[k].FEC :=3D Note that any parent link and any child link is identified by the neighboring node k of node i at the remote end of the link and by its (IPv4-)RouterId[k]. Alternative link identifications are not considered here for reasons of simplification. If the tree branches at the source node s itself, a packet/message is to be sent out, each provided with a different TREE ROUTE TLV. Accordingly we will determine each initial link, stored in linkTo, and the respective initial TREE ROUTE TLV, given by TLV[1],...,TLV[j] that it contains. Hummel & Loke Febuary 1999 [Page 12] Explicit Tree Routing Exp. Aug 1999 The variable j (same scope of the TREE ROUTE TLV) indicates the number of TLVs inside the TREE ROUTE TLV being built. It is initialized to 0 to indicate that TREE ROUTE TLV is empty: - initTreeRouteTLV ( ) { j:=3D0 } j will be incremented whenever a TLV is added to the TREE ROUTE TLV: - addBracketOpenTLV ( ) { j++; TLV[j] :=3D "("-TLV; }; - addBracketClosedTLV ( ) { j++; TLV[j] :=3D ")"-TLV; }; - addLinearSequenceTLV ( ) { j++; TLV[j] :=3D linearSequenceTLV; }; - addFECTLV ( ) { j++; TLV[j] :=3D TN[currentNode].FEC; }; Temporarily we will build up linearSequenceTLV which contains a sequence of hops given by LINK[1],...,LINK [jj]. It starts being empty by initLinearSequenceTLV ( ) { jj:=3D0 ; } It is filled with another link by: addChildLink ( INT k ) { INT childNode; jj++; childNode :=3D NT[currentNode].ChildLink [k]; LINK [jj] :=3DRouterId [childNode]; } You may check whether links are already contained : linearSequenceTLVNotEempty ( ) {returns k >0} By the following loop, source node s sends out the message/packets to the right neighbor nodes conveying the right TREE ROUTE TLVs: for (k :=3D 1; k<=3D TN[s].ChildLinkCount; k++) { INT LinkTo, j, jj ; initTreeRouteTLV ( ) ; // zero TLVs inside of TREE ROUTE TLV initLinearSequenceTLV ( ) ; // zero links inside of linearSequenceTLV= linkTo :=3D NT[s].ChildLink[k]; addChildLink ( k ); // add first child node buildTreeRouteTLV ( LinkTo ); //recursive subroutine ...send out the packet/message with the built TREE ROUTE TLV Hummel & Loke Febuary 1999 [Page 13] Explicit Tree Routing Exp. Aug 1999 to neighbor LSR given by LinkTo. } Note: you may supress sending the TREE ROUTE TLV as well if it only contained "("-TLV, ")"-TLV and no essential information. Definition of subroutine buildTreeRouteTLV: buildTreeRouteTLV ( currentNode ) { if (NT[currentNode].IsLeaf =3D=3D TRUE ) then { if linearSequenceTLVNotEmpty ( ) then { addLinearSequenceTLV ( ); initLinearSequenceTLV ( ); } addBracketOpenTlv ( ); addFecTlv ( ); //i.e. add NT[currentNode].FEC if present addBracketClosedTlv ( ); } if (NT[currentNode].ChildLinkCount =3D=3D 1) then { // node is not branching out addChildLink(1) ; // to the link sequence tlv buildTreeRouteTlv (NT[currentNode].ChildLink[1] ); } elseif (NT[currentNode].ChildLinkCount > 1) then { for (k:=3D 1;k<=3D NT[currentNode].ChildLinkCount;k++) { addBracketOpenTlv ( ); addChildLink(k) ; // to the link sequence tlv buildTreeRouteTlv ( NT[currentNode].ChildLink[k] ); addBracketClosedTlv ( ); } } } //-----------end of subroutine BuildTreeRouteTLV------------ Hummel & Loke Febuary 1999 [Page 14] Explicit Tree Routing Exp. Aug 1999 APPENDIX B Decoding Algorithm DA, to be called by any node that has received the TREE ROUTE TLV, as to determine: - all child links and respective child TREE ROUTE TLVs, - whether current node is (also) leaf node, - if applicable and if provided, the FEC for current leaf node. An initial analysis of the received TREE ROUTE TLV may fill array incomingTLV [i] for i=3D1,..,n with all its n TLVs in sequence. incomingTLV [1] will contain a "Linear sequence of hops"-TLV which starts with a "first hop address". If this address does not match the current node's address then a loose route section is traversed and the the message/packet must be forwarded to that address based on the current node's own decision and without changing the TREE ROUTE TLV. Otherwise, DA determines subsequently each adjacent child link, by retrieving the Router Id of each node the message/packet shall be forwarded to - according to the received TREE ROUTE TLV. This IPv4 address information is stored in childNodeRouterId. Simultaneously, DA fills up outgoingTLV[1],...,outgoingTLV[j] which will be contained in /make up the childTreeRouteTLV. childTreeRouteTLV is started as an empty TLV by: initChildTreeRouteTLV ( ) {j:=3D0;} and is filled by: addCurrentTLV ( ) { if (currentTLV |=3D NULL) { j++; outgoingTLV [j] :=3D currentTLV; } } The first hop entry of "Linear Sequence of Hops"-TLV While being the currentTLV may be read: readFirstElementOfSequence ( ) { return Router ID of first element of currentTLV // which is a "Linear Sequence of Hops" -TLV Hummel & Loke Febuary 1999 [Page 15] Explicit Tree Routing Exp. Aug 1999 } By calling linearSequenceTLVnotEmpty ( ) { returns number of links > 0; } we can check whether the remaining TLV has become empty or not. currentNodeIsLeaf :=3D FALSE; FECforCurrentNode :=3D NULL; DA ( ); // child -links and -TLVs handled inside if currentNodeIsLeaf then { // handle the received message/packet being a leaf node, // evaluate FECforCurrentNode (if not equal NULL); } DA ( ) //---------Decoding Algorithmus DA------------------ { INT i, nestingLevel, childNodeRouterId; CurrentTLV :=3D incomingTLV [1]; myOwnRouterId:=3D readFirstSequenceElementOfFirstTLV ( ); if (myOwnRouterId "does not match myself") then { exit; // loose route section | forward message with unchanged // TREE ROUTE TLV based on own decision } else { delete first hop from incomingTLV [1] which is a "Linear sequence of hops"-TLV. if (the remaining incomingTLV [1] has become empty) then i:=3D1; else i:=3D 0; j:=3D0; nestingLevel:=3D0; childNodeRouterId :=3D NULL; initChildTreeRouteTLV ( ); while (i 0 ) then addCurrentTLV ( ) ; if (currentTLV =3D=3D "FEC"-TLV & nestingLevel=3D=3D1 ) then FECforCurrentNode :=3D currentTLV; if ((currentTLV =3D=3D "Linear Sequence of hops"-TLV) && nestingLevel =3D=3D1) then { childNodeRouterId:=3D readFirstElementOfSequence ( ); addCurrentTLV ( ); } if ((currentTLV =3D=3D ")"- TLV) && (nestingLevel =3D=3D0)) the= n { if (childNodeRouterId =3D=3D NULL) then { currentNodeIsLeaf :=3D TRUE; } else { current node is transit node: forward message/packet to child node given by childNodeRouterId, conveying childTreeRouteTLV. processReceivedMessage ( );//e.g. do label binding | initChildTreeRouteTLV ( ); childNodeRouterId :=3D NULL; } } } // ... while loop } // ------------ End of Decoding Algorithm DA ------------ A note about calling processReceivedMessage inside of DA: There may be more information, e.g. a new label, to be forwarded to the next child node. Furthermore,a Next Hop Label Forwarding Entry (NHLFE) may have to be made which relates to the specific child link. Hummel & Loke Febuary 1999 [Page 17]