CCAMP Working Group T. Ozugur Category: Internet Draft D. Papadimitriou Document: draft-ozugur-ccamp-gmpls-label-flag-00.txt Alcatel May 2002 Label Set Priority and Flagging Operations draft-ozugur-ccamp-gmpls-label-flag-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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 document presents the GMPLS Signaling mechanisms referred to as generalized label flagging method, and RSVP-TE/CR-LDP specific signaling extensions formats needed to ease forward-link label unavailability when the downstream label selection is restricted by the upstream node using the Label Set. It also relaxes backward-link label collision when the downstream label collides with competing label selection. This method introduces the Flagged Label Set object/TLV in order to prioritize the reservation of the labels included in the Label Set enabling to decrease the forward- and backward-link blocking probability. 1. Conventions used in this document 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 RFC-2119. T.Ozugur et al. Expires November 2002 1 draft-ozugur-ccamp-gmpls-label-flag-00.txt May 2002 2. Introduction In Generalized MPLS context (see [GMPLS-ARCH] and [GMPLS-SIG]), a Generalized Label may represent a specific fiber, wavelength, or timeslot. If wavelength converters are available at a given optical LSR, a label, which represents the wavelength sub-interface (for a given incoming interface) may correspond to another wavelength at a given outgoing interface. Otherwise, incoming-outgoing pair uses the same wavelength assigned through their corresponding label value for this connection. In this context, a connection setup request may fail due to one of two blocking events, namely forward-link and backward-link blocking. Forward-link blocking occurs when the resources are not available on the forward (i.e. outgoing) link while the signalling request travels in the downstream direction. Backward-link blocking happens when for more than one connection request the same wavelength (i.e. the same label) over the same interface is selected i.e. when the signalling response flows towards the ingress node. Forward-link blocking is the reasoning of insufficient label resources and non- load balancing routing algorithms. Backward-link blocking happens due to label conflict during (label) reservation. Therefore, assigned labels may collide and result in failure during the connection establishment. The Label Set (see [GMPLS-SIG]) is used to restrict label range values that may be used for a particular LSP setup between two peers. The receiver of a Label Set must restrict its label choice (i.e. the selection) to one of the label within the set. Thus, the labels included in the Label Set restrict the labels that can be selected by the egress node. However, the selection method can be improved in order to provide an efficient solution to the label-collision problem and in turn decrease the wavelength blocking probability. This even if feedback is allowed using the Acceptable Label Set commodity (see [GMPLS- SIG]). This document presents the GMPLS Signalling mechanisms (referred to as generalized label flagging method) and RSVP-TE/CR-LDP specific signaling extensions formats needed to ease forward-link label unavailability when the downstream label selection is restricted by the upstream node using the Label Set (see [GMPLS-SIG]). It also relaxes backward-link label collision when the downstream label collides with competing label selection. This method introduces the Flagged Label Set object/TLV in order to prioritize the reservation of the labels included in the Label Set and enabling to decrease the forward- and backward-link blocking probability. In order to prioritize the label reservation, each set of labels is inserted by each node along the path into the Flagged Label Set object/TLV with a certain priority. Each node keeps track of each label by using a local timestamp indicating when the label has been reserved but not selected yet with respect to any other previous label set. A pool, which is referred to as Flagged Pool (besides the T.Ozugur et al. Expires November 2002 2 draft-ozugur-ccamp-gmpls-label-flag-00.txt May 2002 Used Pool and Available Pool), points to these labels. Therefore, this pool provides a gray area for the labels, which are subject to collision, and thus being in an intermediate state between the labels belonging to the Used Pool (reserved and selected) and the ones belonging to the Available Pool (neither reserved or selected). The Flagged Pool uses a local timestamp information for label selection purposes. Moreover, the corresponding Flagged Label Set object/TLV restricts the choice of the downstream node by using several priority levels. This enables relaxing the usage of the label set. In turn, by means of a specific threshold mechanism the number of label collisions during the label selection phase can be minimized. Consider for instance the following network topology and lambda LSP requests from source to destination: LSP1 (1 -> 6), LSP2 (2 -> 4) and LSP3 (3 -> 5) 2 4 | | | | | | 1 ----- A ----- B ----- C ----- D ----- 6 | | | | | | 3 5 In this context, the following situations would have occurred when Node 1 then Node 2 sends sequentially (or at least Node 1 Path message is sent before the Resv message of the first connection request reaches Node A) a connection request to setup LSP1 and LSP2, respectively. The Node A Label Set policy may be as follows: 1. LSP1 Label Set is disjoint from LSP2 Label Set: no blocking 2. LSP1 Label Set overlap with LSP2 Label Set: in order to avoid blocking, the resulting LSP2 Label Set should include the label corresponding to the Label Set values of LSP2 minus the overlapping values. In order to give precedence the following is considered using the proposed approach: set non-intersecting values to a higher priority (and include them in a default Label Set object/TLV) and the intersecting ones to a lower priority (and include them in a Flagged Label Set object/TLV). At subsequent nodes, selection will be first performed on highest priority labels. 3. LSP1 and LSP2 Label Set are embedded: 3a. LSP1 Label Set larger than LSP2 Label Set: No action capable to avoid blocking since dependent on subsequent decisions by the corresponding egress nodes. T.Ozugur et al. Expires November 2002 3 draft-ozugur-ccamp-gmpls-label-flag-00.txt May 2002 3b. LSP1 Label Set smaller than Node 2 Label Set: Node A to reduce Node 2 Label Set to their difference in order to avoid any blocking probability. In order to give precedence the following is considered using the proposed approach: set non-intersecting values to a higher priority and the intersecting ones to a lower priority. Corresponding labels are respectively included in a default (non-flagged) Label Set object/TLV or in a Flagged Label Set object/TLV. At subsequent nodes, selection will be first performed on highest priority labels. The proposed (backward compatible) approach enable to enhance the processing that would normally occur with common Label Set policy by enabling to cover cases 2 and 3b in a more effective way. For instance, as currently defined in [GMPLS-SIG], Node 1 (Node 2) for LSP1 (for LSP2) would use a Label Set object/TLV including the label range [1-6] ([3-8]) restricted by Node A to [1-6] ([5-8], respectively). Consider now that Node 6 support only label 6 and Node 4 only label 4. In such a case, LSP2 connection would be rejected. Using the Flagged Label Set approach, Node A would use a higher priority non-Flagged Label Set including the label range [5- 8] and a lower priority Flagged Label Set including the label range [3-4]. Obviously, if both requests arrives simultaneously at Node A, LSP1 (LSP2) would use the following label set {[1-2], [3-6]} ({[7- 8], [3-6]}, respectively). 4. Generalized Label Flagging Method This section modifies the Label Set object/TLV to be carried in the Path/Label Request message while requesting a label. To deal with the label blocking issues (i.e. unavailability and collision) described in the Section 2, a modified form of Label Set object/TLV is required, which is referred to as Flagged Label Set object/TLV. This object/TLV is identical to the Label Set object/TLV as defined in [GMPLS-SIG] except that it introduced a new Flag field in its Reserved field. 4.1. Flagged Label Set Object/TLV The Label Set is used to limit the label choices of a downstream node to a set of acceptable labels. This limitation applies on a per hop basis. The Label Set can for instance be specified on an end-to- end basis in the optical domain, where there is a sequence of interfaces which cannot support wavelength conversion (CI-incapable) and require the same wavelength be used end-to-end over a sequence of hops, or even an entire path. A Label Set is composed of one or more Label Set objects/TLVs [GMPLS-SIG] including (or excluding) one or more elements referred T.Ozugur et al. Expires November 2002 4 draft-ozugur-ccamp-gmpls-label-flag-00.txt May 2002 to as a sub-channel identifiers which have the same format as a Generalized Label. Here, the Label Set is composed of one or more Flagged Label Set objects/TLVs. The format Flagged Label Set object/TLV is the same as the canonical Label Set object/TLV except that it includes a Flag field. In RSVP-TE, the Flagged Label Set object uses Class-Number TBA (of form 0bbbbbbb) and the C-Type of 1. In CR-LDP, the corresponding Type field in the Flagged Label Set TLV is TBA. The format of the Flagged Label Set object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(TBA)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Flag | Reserved | Label Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel 1 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel N | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Action: 8 bits (see [GMPLS-SIG]) Flag: 4 bits: The Flag field is subdivided as follows: Priority (P): 2 bits Indicates the priority of the Flagged Label Set object 0x00 Highest priority (for backward compatibility) 0x01 Second highest priority 0x10 Third highest priority 0x11 Lowest priority Operation (O): 2 bits Indicates the flagging operation (see Section 5) 0x00 Non-Flagging Operation (backward compatibility) 0x01 Aggressive Flagging Operation 0x10 Full Flagging Operation 0x11 Reserved Reserved: 6 bits T.Ozugur et al. Expires November 2002 5 draft-ozugur-ccamp-gmpls-label-flag-00.txt May 2002 This field is reserved. It MUST be set to zero on Transmission and MUST be ignored on receipt. Label Type: 14 bits Indicates the type and format of the labels carried in the object. Values match the C-Type of the appropriate Label object. Only the low order 8 bits are used in this field (see [GMPLS-SIG].) See [GMPLS-SIG] for a description of the other fields. The format of the Flagged Label Set 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type (TBA by IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Flag | Reserved | Label Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel 1 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel N | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2. Flagged Label Set Object/TLV Processing A Path message may carry more than one Flagged Label set object/TLV, where each object represents a different priority according for instance to their elapsed selection period (also referred to as selection time) or the corresponding LSP Setup priority. Flagged Label Set objects/TLVs are the same as Label Set except for the Flag field which includes the Priority and Operation fields. The Priority of the Flag field indicates the selection priority of the corresponding labels. Flagging operations are described in Section 5. Note that the Flagged Label Set objects/TLVs do not carry any timestamp or clock information. Time-related information is only stored locally within the Flagged Pool (FP) structure. The priority indicated in the Flagged Label Set object/TLV is inferred from a certain time interval referring at which the same labels have been previously selected within another label set. When processing a Path/Label Request message, the LSR first investigates the label sub-objects listed in the highest priority Label Set object(s)/TLV(s) before the ones included in lower priority Flagged Label Set objects/TLV. The highest priority Label Set object/TLV T.Ozugur et al. Expires November 2002 6 draft-ozugur-ccamp-gmpls-label-flag-00.txt May 2002 corresponds exactly to the Label Set object/TLV currently defined in [GMPLS-SIG]). Consequently the proposed method is fully backward compatible. Moreover, each LSR keeps an entry for each label using local timestamps indicating when the label has been selected. This information is stored in the Flagged Pool (FP) at each LSR. When processing a Path/Label Request message, the LSR investigates whether the labels listed in the Flagged Label Set object(s)/TLV(s) are in the FP. If any label is in the FP, the LSR calculates the difference of selection time (i.e. clockûtimestamp) for this label. The timestamp refers to the time when this label has been previously selected. If the value of local time of the label indicates a lesser priority than the priority of the label's current Flagged Label Set object/ TLV, the LSR MUST insert the label into a Flagged Label Set object/ TLV with a lesser priority. If this object doesnÆt exist, the LSR inserts a new Flagged Label Set object/TLV into the Path/Label Request message before forwarding to downstream. The key points of the Flagged Label Set object/TLV are as follows: - FPs store the local timestamp of the label when it is suggested; however, by taking difference of (local clock- timestamp), it reaches global information to prioritize the Flagged Label Set objects. - LSRs use local clock timing without any synchronization. However, by taking (local clock-timestamp) difference and locating labels within the Flagged Label Set objects/TLVs according to this difference, makes the Flagged Label Set objects globally prioritized without using synchronization. 4.3. Backward Compatibility If the Flagged Label Set object/TLV and its processing is not supported, the corresponding object/TLV is ignored and not further processed. Moreover, when the Flagged Label Set object/TLV is supported its highest priority (see Section 4.1) corresponds exactly to the Label Set object/TLV as defined in [GMPLS-SIG]. 5. Flagging Operation and Procedure The flagging operation using Flagged Label Set objects/TLVs at each LSR can be grouped into two modes in addition to the Non Flagging default operation: 1) Aggressive Flagging Operation, 2) Full Flagging Operation. The Operation (O) field in the Flagged Label Set object indicates which flagging operation is in use. In the Aggressive Flagging Operation method, the label is extracted from the Flagged Label Set object(s) and Label Set object(s), and the label is not advertised in any of these objects while forwarding T.Ozugur et al. Expires November 2002 7 draft-ozugur-ccamp-gmpls-label-flag-00.txt May 2002 the Path message in the downstream direction. In Full Flagging Operation method, any label whose in the Flagged Pool, is inserted into a corresponding Flagged Label Set object before forwarding the Path message downstream. The Flagged Label Set object/TLV with the priority field set to 0x11 has the lowest priority and represents the labels, which have been recently selected for another LSP. The Flagged Label Set object/TLV with the priority field set to 0x10 has the third highest priority. In other words, labels within this object with the priority field set to 0x10 have been selected some time ago such that the probability of previous requesting LSP selected a different label is lower. The Flagged Label Set object/TLV with the priority field set to 0x01 has the second highest priority includes labels that have been selected for a long time ago such that the probability of previous requesting LSP selected a different label is quite low. Last, the Flagged Label Set object/TLV with the priority set to 0x00 has the highest priority and include labels that are not selected for any other LSPs (or any previous selection has elapsed) such that the blocking probability due to their selection is the lowest. At each LSR, the flagging operation is itemized as follows: 1. A path message with Generalized Label Request object/TLV arrives to the LSR. 2. Investigate each label within the Flagged Label Set objects/TLV. 3. If the label is an element of the Available pool, then keep the Label within the Flagged Label Set with its current Flag field settings. 4. If the label is not an element of the Available Pool, then check whether the label is an element of Flagged Pool (FP). 5. If the label is an element of the FP, the label is inserted into the corresponding Flagged Label Set object/TLV and processed with respect to its operation mode (aggressive 0x01 or full flagging 0x10) 6. If the label is not an element of the AP or FP, then it is an element of Used Pool (UP), then remove the label from Flagged Label Set object/TLV. 7. If all labels within the Flagged Label Set objects/TLVs are investigated, terminate the procedure. Otherwise, go to item 1. The downstream LSR SHOULD NOT insert a label into a higher priority Flagged Label Set object than its current Flagged Label Set object. Moreover, when the egress node receives the Path message, it randomly selects a label among the labels within the Flagged Label Set object starting with the highest priority one. For example, if there is no labels in the Flagged Label Set with the priority field set to 0x00, then the egress node randomly selects a label among the labels within the next (highest) priority Flagged Label Set, which is with the priority field set to 0x01, and so on. T.Ozugur et al. Expires November 2002 8 draft-ozugur-ccamp-gmpls-label-flag-00.txt May 2002 6. Acknowledgments Valuable comments and input were received from numerous people, including Dominique Verchere, Jim Jones, Francesco Masetti, Kevin Hardee and Jason Jue. 7. Security Considerations This draft introduces no new security considerations to the Generalized MPLS RSVP-TE [GMPLS-RSVP]] and CR-LDP [GMPLS-LDP] Signalling extensions. 8. Intellectual Property Considerations Alcatel is seeking patent protection on technology described in this Internet-Draft. If technology in this Internet-Draft is adopted as a standard, Alcatel agrees to license, on reasonable and non- discriminatory terms, any patent rights it obtains covering such technology to the extent necessary to comply with the standard. 9. References [GMPLS-SIG] L.Berger et al., ôGeneralized MPLS - Signaling Functional Descriptionö, draft-ietf-mpls-generalized- signaling-08.txt, work in progress, April 2002 [GMPLS-RSVP] L.Berger et al., ôGeneralized MPLS Signaling - RSVP-TE Extensionsö, draft-ietf-mpls-generalized-rsvp-te- 07.txt, work in progress, April 2002. [GMPLS-LDP] L.Berger et al., ôGeneralized MPLS Signaling û CR-LDP Extensionsö, draft-ietf-mpls-generalized-cr-ldp-06.txt, work in progress, April 2002. [GMPLS-ARCH] E.Mannie et al., ôGeneralized Multi-Protocol Label Switching (GMPLS) Architectureö, work in progress, draft-ietf-ccamp-gmpls-architecture-02.txt, FebÆ02. 10. Author's Addresses Timucin Ozugur (Alcatel) 1000 Coit Road M/S CT02 Plano, TX 75075 USA E-mail: tim.ozugur@alcatel.com Phone: (972) 477-2737 Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1 B-2018 Antwerp, Belgium Email: dimitri.papadimitriou@alcatel.be Phone: (+32) 3 2408491 T.Ozugur et al. Expires November 2002 9