Previous

Content

 

2.11. Label Distribution Procedures

  

Procedures in this section are for label bindings used in hop-by-hop routed paths. Labels will correspond  to address prefixes in routing tables. Some procedure are executed by the downstream LSR, and some by the upstream LSR.
Downstream LSR's label binding procedures
  1. The Distribution procedure.
     
  2. The Withdrawal procedure.
Upstream LSR's label binding procedures
  1. The Request procedure.
     
  2. The NotAvailable procedure.
     
  3. The Release procedure.
     
  4. The LabelUse procedure.
Downstream LSR: Distribution procedure
This procedure is used by a downstream LSR to determine when it should distribute a label binding for a particular address prefix to its label distribution peers. There are four different distribution procedures:
  1. PushUnconditional
     
      Let Rd and Ru be downstream and upstream LSR respectively. Address prefix X is in Rd's routing table. Ru and Rd are label distribution peer with respect to X. Whenever these conditions hold, Rd must bind a label to X and distribute that binding to Ru. Rd is responsible to keep track bindings it distributes to Ru, and to make sure that Ru always has these bindings.

    This procedure would be used by LSRs performing unsolicited downstream label assignment in the Independent LSP Control Mode.
         		  
  2. PushConditional
     
      Again with Rd and Ru. X is an address prefix in Rd's routing table. Ru and Rd are label distribution peer with respect to X. Rd is either an LSP Egress or an LSP Proxy Egress for X, or Rd's L3 next hop for X is Rn, being Rn <> Ru, and Rn has bound a label to X and distributed that binding to Rd. As soon as these conditions all hold, Rd should bind a label to X and distribute that binding to Ru.

    Whereas PushUnconditional causes the distribution of label bindings for all address prefixes in the routing table, PushConditional causes the distribution of label bindings only for those address prefixes for which one has received label bindings from one's LSP next hop, or for which one does have an MPLS-capable L3 next hop.

    This procedure would be used by LSRs which are performing unsolicited downstream label assignment in the Ordered LSP Control Mode.
         		  
  3. PulledUnconditional
     
      Again with Rd and Ru. X is an address prefix in Rd's routing table. Ru and Rd are label distribution peer with respect to X. Ru has explicitly requested that Rd bind a label to X and distribute the binding to Ru. As soon as these conditions all hold, Rd should bind a label to X and distribute that binding to Ru.

    When Ru has requested to Rd to bind a label to X and X is not in Rd's routing table, or Rd is not label distribution peer to Ru with respect to X, Rd must inform Ru that it cannot provide a binding at this time.

    If Rd has already distributed a binding for X to Ru, and it receives a new request from Ru for a binding for X, it will bind a second label, and distribute this new binding to Ru. The first binding remains in effect.

    This procedure would be used by LSRs performing downstream-on-demand label distribution using Independent LSP Control Mode.
         		  
  4. PulledConditional
     
      Again with Rd and Ru. X is an address prefix in Rd's routing table. Ru and Rd are label distribution peer with respect to X. Ru has explicitly requested that Rd bind a label to X and distribute the binding to Ru. Rd is either an LSP Egress or an LSP Proxy Egress for X, or Rd's L3 next hop for X is Rn, being Rn <> Ru, and Rn has bound a label to X and distributed that binding to Rd. As soon as these conditions all hold, Rd should bind a label to X and distribute that binding to Ru.

    Note that if X is not in Rd's routing table and a binding for X is not obtainable via Rd's next hop for X, or if Rd is not label distribution peer of Ru for X, then Rd must inform Ru that it cannot provide a binding at this time. However, if the only condition that fails is that Rn has not yet provided a label to Rd, then Rd must defer any response to Ru until such time it has received a binding from Rn.

    This procedure would be used by LSRs that are performing downstream-on-demand label allocation in the Ordered LSP Control Mode.    		  
Distribution Procedure additional requeriments
 
Irrespective of the distribution procedure used, if a label binding for an address prefix has been distributed by a downstream LSR Rd to an upstream LSR Ru, and if at any time the attributes of the binding change, then Rd must inform Ru of the new attributes, even though, in downstream-on-demand label allocation, Ru does not issue a new binding's request.
 
If an LSR is maintaining multiple routes to a particular address prefix, it is a local matter as to whether that LSR binds multiple labels to the address prefix (one per route), and hence distributes multiple bindings.
 
Downstream LSR: Withdraw procedure
 
In this case, there is only a single procedure as follows. When LSR Rd decides to break a binding L-X, then this unbinding must be distributed to all LSRs to which the binding was previously distributed.
 
The unbinding L-X should be distributed by Rd to Ru before a new binding, say L-Y, where X <> Y, is distributed. If Ru receives the new binding before the respective unbinding, then for a period of time, Ru would label both packets, matching X or matching Y, with the label L.
 
Distribution and withdrawal are done using a label distribution protocol (LDP). All LDPs require that a label distribution adjacency be established between two label distribution peers (except on implicit peering). When an adjacency between two LSRs is brought down by either peer, all binding received over that adjacency must be considered to have been withdrawn.
 
As long as adjacency remains in place, binding withdrawing must always be done explicitly. If a second label is bound to an address prefix, the first binding should not be withdrawed, but the new label should be bounded; this, to support multi-path routing. If a second address prefix is bound to a label, the first binding should not be withdrawed, but this label should be used for both address prefixes.
 
Upstream LSR: Request Procedure
 
   

 
The RequestProcedure is used by the upstream LSR for an address prefix to determine when to explicitly request to a downstream LSR to bind a label to that prefix and distribute the binding. There are three procedures:
  1. RequestNever
     
      Never make a request. To be used when the downstream router uses PushConditional or PushUnconditional procedures (unsolicited downstream label distribution) and Liberal Retention Mode is in use.
         		  
  2. RequestWhenNeeded
     
      Make a request when ever the L3 next hop to X changes, or when a new prefix is learned and one doesn't have already a binding for this prefix. To be used whenever Conservative Label Retention Mode is in use.
         		  
  3. RequestOnRequest
     
      Make a request whenever a request is received and the LSR is not capable of being an LSP Ingress. When Rd receives such request from Ru, and it has already distributed a binding to Ru for this address prefix, then Rd shall assign a new (distinct) label, bind it to X, and distribute that binding. To be used by LSRs doing downstream-on-demand label distribution, but not label merging.  
Upstream LSR: NotAvailable Procedure
Being Ru and Rd distribution peers for X, and Rd is Ru's L3 next hop for X, and Ru requests a binding for X from Rd, but Rd replies it cannot provide this binding at this time, then Ru should respond with the NotAvailable procedure. There are two types:
  1. RequestRetry
     
      Meaning, request again at a later time. To be used when doing downstream-on-demand label distribution.
         		  
  2. RequestNoRetry
     
      Meaning, never reissue the request, because we are assuming that Rd will provide the binding automatically when it is available. To be used when doing PushConditional or PushUnconditional procedures, i.e., unsolicited downstream label distribution is used.  
Upstream LSR: Release Procedure
Having Rd and Ru as label distribution peers for address prefix X. Later, if Rd does not happen to be Ru's L3 next hop for X, or has ceased to be Ru's L3 next hop for X, then Ru will not be using the label. The Release Procedure determine how Ru acts in this case. There are two possible procedures:
  1. ReleaseOnChange
     
      Ru should release the binding and inform to Rd that is has done so. Used to implement Conservative Label Retention Mode.
         		  
  2. NoReleaseOnChange
     
      Ru should maintain the binding, so that it can use it again immediatly if Rd later becomes Ru's L3 next hop for X. This procedure would be used to implement Liberal Label Retention Mode.  
Upstream LSR: labelUse Procedure
 
Suppose Ru has received a binding L-X from Rd; in fact, Rd is Ru's L3 next hop for X. Ru will use this binding as long as Rd is Ru's L3 next hop for X. If, at the time the binding is received, Rd is not Ru's L3 next hop for X, Ru does not make use of the binding at this time. However, Ru may start using the binding some time later, when Rd becomes Ru's L3 next hop for X. The LabelUse procedure determines how Ru makes use of Rd's binding. There are two possibilities:
 
  1. UseInmediate
     
      Put the bind into use inmediately. At any time Ru has a binding for X from Rd, and Rd is Ru's L3 next hop for X, Ru will also be Ru's LSP next hop for X. This procedure is used when loop detection is not used.
         		  
  2. UseIfLoopNotDetected
     
      Apply the same procedure as UseInmediate, unless Ru has detected a loop in the LSP. If a loop has been detected, Ru will discontinue the use of label L for forwarding packets to Rd. This procedure is used when loop detection is in use. The procedure continues until next hop for X changes, or until the loop is no longer detected.  
Supported Combination of Procedures
 
MPLS scheme which governs the interaction of Ru and Rd (being Ru and Rd label distribution peers; Ru is the upstream router and Rd is the downstream router) can be described as a quintuple of procedures <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. Since there is only one Withdraw Procedure it need not be mentioned. A * appearing in one of the position is a wildcard, meaning that any procedure of this category can apply; N/A means that no procedure in this category is needed. Schemes specified below are those supported by the MPLS architecture.
 
   

 
  1. Schemes that support Label Merging
     
     
    1. Those based in Independent Control Mode. They are four (4):
       
       
      1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseInmediate>

        This combination corresponds to unsolicited downstream label distribution with independent control, liberal label retention mode, and no loop detection.
         
      2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>

        This combination corresponds to unsolicited downstream label distribution with independent control, liberal label retention mode, and loop detection.
         
      3. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseInmediate>

        This combination corresponds to downstream-on-demand label distribution with independent control, conservative label retention mode, and no loop detection.
         
      4. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected>

        This combination corresponds to downstream-on-demand label distribution with independent control, conservative label retention mode, and loop detection.
         
      		  
    2. Those based in Ordered Control Mode.They are three (3):
       
       
      1. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange, *>

        This combination corresponds to unsolicited downstream label distribution with ordered control (initiated by the egress LSR), and conservative label retention mode. Loop detection is optional.
         
      2. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>

        This combination corresponds to unsolicited downstream label distribution with ordered control (initiated by the egress LSR), and liberal label retention mode. Loop detection is optional.
         
      3. <PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>

        This combination corresponds to downstream-on-demand label distribution with ordered control (initiated by the ingress LSR), and conservative label retention mode. Loop detection is optional.
         
      		  
    		 
  2. Schemes that do not support Label Merging
     
      Having ATM switches R1, R2, R3, and R4 which do not support label merging but are being used as LSRs. Suppose that L3 hop-by-hop path for address prefix X is <R1,R2,R3,R4>, and that packets destined for X can enter the network at any of these LSRs. Since there is no multipoint-to-point capability, the LSPs must be realized as point-to-point VCs, which means that there needs to be three such VCs for address prefix X: <R1,R2,R3,R4>, <R2,R3,R4>, and <R3,R4>. The MPLS scheme in use between R1 and R2 must be one of the following:
    1. Those based in Independent Control Mode. They are two (2):
       
       
      1. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseInmediate>

        This combination corresponds to downstream-on-demand label distribution with independent control and conservative label retention mode, without loop detection.
         
      2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>

        This combination corresponds to downstream-on-demand label distribution with independent control and conservative label retention mode, with loop detection.
      		  
    2. Those based in Ordered Control Mode. This is one (1):
       
       
      1. <PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>

        This combination corresponds to downstream-on-demand label distribution with ordered control (initiated by the ingress LSR), conservative label retention mode, and optional loop detection. The use of RequestOnRequest will cause R4 to distribute three labels for X to R3; R3 will distribute two labels for X to R2; and R2 will distribute one label for X to R1.
      		  
    		 
Interoperability Considerations
Here, rules are specified to prevent a pair of label distribution peers from adopting procedures which lead to infeasible MPLS schemes. Rules are:
  1. Each LSR must state whether it supports label merging.
     
  2. If Rd does not support label merging, it must choose either PulledUnconditional or PulledConditional procedures. If it chooses PulledConditional, Ru is forced to use the RequestRetry procedure. That is, if Rd does not support label merging, its preferences take priority when the MPLS scheme is chosen.
     
  3. If Rd does not support label merging, but Rd does, Ru must choose either the RequestRetry or RequestNoRetry procedure. This forces Rd to use PulledConditional or PulledUnconditional procedures respectively. That is, if only one of the LSRs doesn't support label merging, its preferences take priority when the MPLS scheme is chosen.
     
  4. If both, Ru and Rd support label merging, then the choice between liberal and conservative label retention mode belongs to Ru. Then, Ru gets to choose either: RequestWhenNeeded/ReleaseOnChange (conservative), or RequestNever/NoReleaseOnChange (liberal). The choice of "push" vs "pull" and "conditional" vs "unconditional" belongs to Rd. If Ru chooses liberal retention mode, Rd can choose either PushUnconditional or PushConditional. If Ru chooses conservative label retention mode, Rd can choose PushConditional, PulledConditional, or PulledUnconditional.
These choices together determine the MPLS scheme in use.
Important keywords to understand and remember
Downstream LSR Procedures
 
  Distribution
 
  PushUnconditional
PushConditional
PulledUnconditional
PulledConditional

Withdraw


Upstream LSR Procedures

  Request
 
  RequestNever
RequestWhenNeeded
RequestOnRequest

NotAvailable

  RequestRetry
RequestNoRetry

Release

  ReleaseOnChange
NoReleaseOnChange

labelUse
 
  UseInmediate
UseIfLoopNotDetected

 
   

 
   

Previous

Content