Internet Draft
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= |<---|R1= |<----|R2= |<-----|R3= |
|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= |----|R1 |--+--|R2= |
|Root | | | | |Leaf|
+-----+ +----+ | +----+
|
| +----+ +----+
+--|R3= |----|R4= |
|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= |-----|R2 |-----|R3= |-----|R4= |----|R5= |
|Root| | | |Leaf| |Leaf| |Leaf|
+----+ +---+ +----+ +----+ +----+
|
|L6 +----+
+---+ L7 |R7= |
|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]=p, whereby P[s]=s. 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 = 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=1,...TN[i].ChildLinkCount
We mark all leaf nodes k=d1,...,dr:
TN[k].IsLeaf := TRUE ;
and, if applicable, provide some of them with an individual FEC:
TN[k].FEC :=
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:=0 }
j will be incremented whenever a TLV is added to the TREE ROUTE TLV:
- addBracketOpenTLV ( ) { j++; TLV[j] := "("-TLV; };
- addBracketClosedTLV ( ) { j++; TLV[j] := ")"-TLV; };
- addLinearSequenceTLV ( ) { j++; TLV[j] := linearSequenceTLV; };
- addFECTLV ( ) { j++; TLV[j] := 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:=0 ; }
It is filled with another link by:
addChildLink ( INT k )
{ INT childNode;
jj++;
childNode := NT[currentNode].ChildLink [k];
LINK [jj] :=RouterId [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 := 1; k<= TN[s].ChildLinkCount; k++)
{ INT LinkTo, j, jj ;
initTreeRouteTLV ( ) ; // zero TLVs inside of TREE ROUTE TLV
initLinearSequenceTLV ( ) ; // zero links inside of linearSequenceTLV
linkTo := 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 == TRUE ) then
{
if linearSequenceTLVNotEmpty ( ) then
{
addLinearSequenceTLV ( );
initLinearSequenceTLV ( );
}
addBracketOpenTlv ( );
addFecTlv ( ); //i.e. add NT[currentNode].FEC if present
addBracketClosedTlv ( );
}
if (NT[currentNode].ChildLinkCount == 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:= 1;k<= 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=1,..,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:=0;}
and is filled by:
addCurrentTLV ( )
{
if (currentTLV |= NULL)
{
j++;
outgoingTLV [j] := 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 := FALSE;
FECforCurrentNode := 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 := incomingTLV [1];
myOwnRouterId:= 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:=1;
else
i:= 0;
j:=0;
nestingLevel:=0;
childNodeRouterId := NULL;
initChildTreeRouteTLV ( );
while (i 0 ) then
addCurrentTLV ( ) ;
if (currentTLV == "FEC"-TLV & nestingLevel==1 ) then
FECforCurrentNode := currentTLV;
if ((currentTLV == "Linear Sequence of hops"-TLV) &&
nestingLevel ==1) then
{
childNodeRouterId:= readFirstElementOfSequence ( );
addCurrentTLV ( );
}
if ((currentTLV == ")"- TLV) && (nestingLevel ==0)) then
{
if (childNodeRouterId == NULL) then
{
currentNodeIsLeaf := 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 := 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]