One document matched: draft-ozugur-ccamp-gmpls-label-flag-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-24 13:17:04 |