One document matched: draft-ietf-mpls-lsp-query-00.txt
Network Working Group P. Ashwood-Smith
Internet Draft A. Paraschiv
Expiration Date: April 2001 Nortel Networks
October 2000
MPLS LDP Query Message Description
draft-ietf-mpls-lsp-query-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."
To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract
This document describes the encoding and procedures for three new LDP
messages, the Query Message and Query-Reply Message and Partial
Query-Reply Message (the last one is almost identical to the Query-
Reply message; therefore all references to the Query-Reply messages
imply the Partial Query-Reply messages as well, unless otherwise
specified). An LER sends a Query message when it needs to find out
information about an LSP. The Query message is sent for an
established LSP. The Query message can be used for LDP LSPs as well
as for CR-LSPs. The queried data is encoded into the Query-Reply
messages. The Query Message carries only the list of hops.
Paraschiv, et. al. [Page 1]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
Contents
1 Introduction ............................................. 3
2 Overview ................................................. 3
2.1 LDP Overview ............................................. 3
2.2 CR-LDP Overview .......................................... 4
3 LDP Message Structure Overview ........................... 4
4 Behavior of LSRs with constraints in handling the query messages 5
4.1 LSR does not support the query messages .................. 6
4.2 LSR cannot share any information ......................... 6
4.3 LSR cannot share some of the queried information ........ 6
4.4 LSR can share the queried information ................... 7
5 Query Message ............................................ 7
5.1 Query Message encoding ................................ 8
5.2 Query Message Procedures ................................. 9
6 Reply Messages .......................................... 10
6.1 Query-Reply Message encoding .......................... 10
6.2 Query-Reply Message Procedures ........................... 12
6.3 Partial Query-Reply Message encoding .................. 13
6.4 Partial Query-Reply Message Procedures ................... 13
7 Query TLVs ............................................... 14
7.1 Query Label TLV .......................................... 15
7.2 Query Merge Flags TLV .................................... 15
7.3 Label TLV ................................................ 16
8 Acknowledgments .......................................... 17
9 References ............................................... 17
10 Author's Addresses ....................................... 18
Paraschiv, et. al. [Page 2]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
Changes from previous version:
o First revision.
1. Introduction
The original Multiprotocol Label Switching (MPLS) architecture
[MPLS-ARCH] was been defined to support the forwarding of data based
on a label. The MPLS architecture does not assume a single label
distribution protocol. A number of different label distribution
protocols are being standardized. This draft describes the query
mechanism for an LSP or CR-LSP. It specifies procedures and encodings
for the new messages added for the query mechanism. Extensions to
the RSVP-TE to provide the same functionality are subject for future
study and will be covered in future draft versions.
The new LDP messages are: Query Message, Query-Reply Message and
Partial Query-Reply Message. The following new TLVs are added to
accommodate the encodings for the new query messages:
- Query TLV
- Query Label TLV
- Query Merge Flags TLV
- Label TLV.
LDP uses the TCP transport for session, advertisement and
notification messages; i.e., for everything but the UDP-based
discovery mechanism. The messages which are added to support the
query mechanism are sent over TCP as well.
2. Overview
2.1. LDP Overview
Label Distribution Protocol (LDP) defined in [LDP Specification]
contains a set of procedures and messages by which Label Switched
Routers (LSR) establish Label Switch Paths (LSP) through a network by
mapping network layer routing information directly to data-link layer
switched paths. LDP associates a Forwarding Equivalence Class (FEC)
with each LSP it creates. The FEC associated with an LSP specifies
which packets are mapped to that LSP.
Paraschiv, et. al. [Page 3]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
2.2. CR-LDP Overview
As described in [Constraint-Base LSP Setup using LDP], Constraint
Base Routing (CR-LDP) offers the opportunity to extend the
information used to setup paths beyond what is available for the
routing protocol.
3. LDP Message Structure Overview
As described in LDP Specification draft, all LDP messages have the
following format:
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| Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mandatory Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit
Unknown message bit. Upon receipt of an unknown message, if U is
clear (=0), a notification is returned to the message originator;
if U is set (=1), the unknown message is silently ignored. The
sections following that define messages specify a value for the U-
bit.
Message Type
Identifies the type of message
Message Length
Specifies the cumulative length in octets of the Message ID,
Mandatory Parameters, and Optional Parameters.
Paraschiv, et. al. [Page 4]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
Message ID
32-bit value used to identify this message. Used by the sending
LSR to facilitate identifying notification messages that may apply
to this message. An LSR sending a notification message in
response to this message should include this Message Id in the
Status TLV carried by the notification message; see Section
"Notification Message".
Mandatory Parameters
Variable length set of required message parameters. Some messages
have no required parameters.
For messages that have required parameters, the required parameters
MUST appear in the order specified by the individual message
specifications in the sections that follow.
Optional Parameters
Variable length set of optional message parameters. Many messages
have no optional parameters.
For messages that have optional parameters, the optional parameters
may appear in any order.
4. Behavior of LSRs with constraints in handling the query messages
Upon receiving a Query message, an LSR has to behave according to its
configuration constraints in handling the query messages and
returning the queried information. The following cases were
identified:
- the LSR does not support the code to handle the messages
for the query mechanism
- the LSR supports the code to handle the messages for the
query mechanism, but it is configured not to return any data
- the LSR supports the code to handle the messages for the
query mechanism, but it is configured not to return part of
the queried data
- the LSR supports the code to handle the messages for the
query mechanism, and it is configured to return all the data
which is queried.
The draft provides flexibility to handle each of the above cases.
Paraschiv, et. al. [Page 5]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
4.1. LSR does not support the query messages
In this case, the LSR has to behave as if it received an unknown
message type. It has therefore to reply with a Notification message.
The notification message is sent upstream and the status is "Unknown
Message Type".
4.2. LSR cannot share any information
In this case, the LSR is able to decode and process the query
messages. However, it is configured to hide all the data. It should
propagate the message after it encodes a zero-length TLV for its hop
in the hop list in the Query message. When Query-Reply message is
received from downstream, the LSR is requested to propagate the reply
message upstream after it encodes the zero-length tlvs for the
queried data. When the ingress receives back the reply, it can
identify which TLVs are empty; it can therefore ignore the zero-
length TLVs and process the rest of the data.
Note: zero-length TLV encoding can be used for all types of queried
information except the merge information. The LSR is requested to
signal the fact that the merging information is private by encoding a
special value in the corresponding merge bits (for more information
on the merge flags values please refer to Query Merge Flags TLV
section).
4.3. LSR cannot share some of the queried information
In this case, the LSR is able to decode and process the query
messages. It has to propagate the query messages. It has to encode
values for the data types that it is willing to return and zero-
length TLVs for values for the data that is hidden.
Note: zero-length TLV encoding can be used for all types of queried
information except the merge information. The LSR is requested to
signal the fact that the merging information is private by encoding a
special value in the corresponding merge bits (for more information
on the merge flags values please refer to Query Merge Flags TLV
section).
Paraschiv, et. al. [Page 6]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
4.4. LSR can share the queried information
This is the normal case for an LSR. In this case, the LSR's behavior
has to follow the query and replies procedures described in the
following sections of the draft.
In order to have consistency among data encoded in the query and
reply messages, each LSR which can propagate the messages has to
encode its information in the query and in the reply messages.
The decision that an LSR can share the queried information has to be
controlled through configuration flags. This way each node along the
path can protect its data if they consider it private.
Note: It would be more efficient to control/restrict the private data
per MPLS cloud (inter MPLS domain) and not per LSR node (inter and
intra MPLS domain). When there are different MPLS clouds which have
nodes belonging to different vendors, the control of the private
information could be restricted to the boundary nodes. Within an MPLS
domain, there should be no restrictions on the queried information.
It would be useful to have some knowledge on which are the nodes on
the boundaries and have only those hiding the queried data. Because
there is no mechanism to identify which are the boundary nodes, this
is subject for future study.
5. Query Message
This sections describes the Query message and its encodings and
procedures. This message is meant to be used to gather information
about an LSP. It can be sent at any time for an established LSP.
The draft currently describes the procedures for the cases when the
Query Message is initiated by the ingress LER. Future versions of
the draft may add the procedures for the query message when issued
from a core LSR or from egress.
The Query Message can be used to gather information about:
- LSRs which form the LSP
- labels along the LSP
- information on what LSRs are merging points along the path
- unused bandwidth (as described in "Improving Topology Data Base Accuracy with LSP Feedback")
- congestion status
- round trip delay
- anything that is needed in the future and can be computed and
encoded in a TLV.
Paraschiv, et. al. [Page 7]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
The queried information is going to be encoded in the Query-Reply
message which is sent back upstream, as a response to the Query
message.
5.1. Query Message encoding
The encoding for the Query message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Query (0x0409) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message.
Label TLV
The label associated to the LSP which is queried. This TLV is a
list of Generalized Label TLVs [OPTICAL reference]. The
Generalized Label TLV provides a more generic encoding for
different types of labels. Most of the time the list has one
element; this is the case when the LSP is not tunneled. For
tunneled LSPs, the Label TLV has more that one element; it has to
behave like a label stack (it contains the previous label and the
tunnel's label). See Section Label TLV for more information on
Label TLV encoding.
Query TLV
What to query. See Section Query TLV for encoding.
Hop Count TLV
Specifies the number of LSR hops that can still be traversed
before the message is dropped due to loop detection. It is
initialized to the max value of 255 (or the configured value, if
any). Every LSR that receives the Query Message has to subtract 1
Paraschiv, et. al. [Page 8]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
from the Hop Count value. The Query message should be dropped if
the hop count value becomes zero; a Notification signaling Loop
Detection should be sent in reply to the sender of the message.
See [LDP Specification] for Hop Count TLV encoding.
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV.
Optional Parameter Length Value
ER TLV var See CR-LDP
The ER TLV is a list of hops. It is used when the Query flag Q3 is
set. Every LSR should add its IP address. The address to be added
should be the outgoing interface address. Addresses are organized as
a last-in-fist-out stack (the first address in TLV is considered the
top). By carrying this TLV in the Query Message and preserving this
order for the hops, we allow the possibility to interwork the Query
Message with the RSVP Path message.
5.2. Query Message Procedures
The LER ingress initiates the Query message. It populates the Query
TLV Parameters according to what kind of information it wants to
gather. The query for an LSP is done by its label. The only data that
the Query Message carries is the list of hops. This way, each node
along the path will have a complete route from source to destination.
The hop list information is useful for network management.
Upon receiving a Query Message, an LSR decodes the label to identify
which LSP is queried. If it cannot find the LSP which is using the
label, it sends back a Notification message. Otherwise, it checks
which is the out label which is bound to the queried in-label and
which is the downstream LSR peer. It replaces the in-label from Label
TLV with the out-label used by the LSP. It then passes the Query
message to the downstream peer. When the Query message gets to a
tunnel, it has to be able to handle both the previous label and the
tunnel's label. The Label TLV behaves like a label stack. The
previous label is pushed and the tunnel label is used. At the end of
the tunnel, we need to pop the stack and start substituting the lower
level labels.
Upon receiving the Query message, the egress node has to reply with a
Query Reply Message. The Query-Reply Message contains the Query TLV
which was received in the Query Message. The Query TLV tells the LSRs
Paraschiv, et. al. [Page 9]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
along the path which information is being queried and allows
intermediate LSRs to piggy back their own queried information on the
Query reply message.
6. Reply Messages
These messages are propagated upstream. There are situations in
which the Query message does not reach the end point of the queried
LSP (e.g. when an LSR along the path is congested, or when it does
not support the Query messages). In these scenarios it would be
useful if the ingress LSR gathered at least some information about
the LSRs which are along the path, up to the one that failed. The
Partial Query-Reply message provides this mechanism. It is
recommended to use the Partial Query-Reply messages when a Query
message fails. There are two types of reply messages:
- Query-Reply message (final reply)
- Partial Query-Reply message.
Both of the reply messages are described in the following sections.
6.1. Query-Reply Message encoding
This message is generated by the end point of the LSP. It is
propagated upstream, by each LSR along the path.
The encoding for the Query-Reply message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Query-Reply (0x0410) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Paraschiv, et. al. [Page 10]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
Message ID
32-bit value used to identify this message.
Query TLV
What is to be queried. See Section Query TLV for encoding.
Message Id TLV
The value of this parameter is the message id of the corresponding
Query message.
Hop Count TLV
Specifies the number of LSR hops that can still be traversed
before the message is dropped due to loop detection. It is
initialized to the max value of 255 (or the configured value, if
any). Every LSR that receives the Query Message has to subtract 1
from the Hop Count value. The Query message should be dropped if
the hop count value becomes zero. See [LDP Specification] for Hop
Count TLV encoding.
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters are:
Optional Parameter Length Value
ER TLV var See CR-LDP
Query Label TLV var See Query Label TLV section
IPV4 specified link feedback TLV See Improving Topology ...
Query Merge Flags TLV var See Query Merge Flags TLV
section
For simplicity we reuse here TLV types defined for CR-LDP and LDP.
They are:
- IPV4 specified link feedback TLV
- ER TLV
- Generalized Label TLV (used in the Query Label TLV encoding)
- Hop Count TLV.
The IPV4 specified link feedback TLV is used when the Q1 flag from
the Query TLV is set. It is used by the egress LER to encode the
bandwidth. For more information on query flags, Q1, ... Q6, refer to
Query TLV section.
The ER TLV is a list of hops. It is used when the Query flag Q3 is
set. Every LSR should add its IP address. The address to be added
should be the outgoing interface address. Addresses are organized as
a last-in-fist-out stack (the first address in TLV is considered the
Paraschiv, et. al. [Page 11]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
top).
The Query Label TLV is a list of labels. It is used when the Query
flag Q2 is set. It is populated with the labels used for the path
which is queried. For tunneled LSPs, the Query Label TLV represents a
list of labels associated to the lowest level tunnel.
If Q3 and Q2 flags are set, the labels should be encoded in the same
order as the hops.
Query Merge Flags TLV is a bit mask. It has variable length and every
two bits in the mask will correspond to an LSR along the path. Its
length is rounded up to the next byte. If Q6 is set, every LSP along
the path will have to set its corresponding bits in the mask. The
bits have to be set in the same order as the labels and hops.
Usually, Q6 is set when Q2 set and/or Q3 set.
For more information for the TLV encodings of the TLVs which are
reused, please see CR-LDP draft, LDP draft and IMPROVING TOPOLOGY
DATA BASE ACCURACY WITH LSP FEEDBACK VIA CR_LDP draft.
6.2. Query-Reply Message Procedures
A Query-Reply message is initiated by an egress node which receives a
Query message, if the egress is able to identify the queried LSP. If
not, the egress replies with a Notification message.
Upon receiving the Query message, the egress node has to reply with a
Query Reply message. The egress node has to encode into the Query-
Reply message a MessageId Tlv. The mapping between a Query and a
Query-Reply Message is done based on the message id. Besides the
MessageId Tlv, the egress has to encode the information that was
queried (bandwidth, path, etc).
After the encoding is done, the query reply message is sent back, on
the reversed path, toward the ingress. Every LSR across the LSP has
to encode its information according to what query flags are set.
Paraschiv, et. al. [Page 12]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
6.3. Partial Query-Reply Message encoding
The Partial Query-Reply message is initiated by tandem LSRs along the
queried path. The message is generated only if the following rules
apply:
- if the Query message asked for partial
replies (the Query message signals this request
through Q8 bit)
- if the tandem LSR is configured to provide partial replies.
The encoding for the Partial Query-Reply message is identical to the
Query-Reply, except the message type. For more details on the
encoding please refer to the Query-Reply encoding.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Query-Reply (0x0411) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4. Partial Query-Reply Message Procedures
The procedures are similar to the Query-Reply's procedures. Upon
receiving a Query message, a tandem LSR will check the flag from the
Query message (Q8) which signals if the partial replies are requested
by the ingress node. If the flag is set, the LSR has to check next if
it is configured to fulfill this request. If the LSR supports partial
replies, it has to create a Partial Query-Reply and encode the
queried data and send it upstream like any Query-Reply messages. It
has then to process the Query message according to the Query message
procedures. When an LSR receives a Partial Query-Reply from upstream,
it should encode its information according to what is queried and
propagate the message. It is recommended to use the Partial Query
mechanism when the Query message fails (when the ingress LER does not
receive a Query-Reply message in response to a Query message).
Paraschiv, et. al. [Page 13]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
7. Query TLVs
The Query TLV is used to specify the information being queried. The
Query TLV travels in the Query message to the egress node, where it
is copied into a reverse flowing Query-Reply messages and used by the
egress and intermediate LSRs to know what information is being
queried.
The format for the Query 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Query TLV (0x0840) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Query Flags can be set according to what the Query is used for.
+--+--+--+--+--+--+--+--+
|Q8|Re|Q6|Q5|Q4|Q3|Q2|Q1|
+--+--+--+--+--+--+--+--+
They can be:
- Q1 : query the bandwidth; if set, the LSR that
receives the Query message has to encode the bandwidth
that is available on the link (unused bandwidth);
- Q2 : query the labels which are associated to each hop in the
path;
- Q3 : query the LSRs which form the LSP which is queried;
if set, the LSR that received the Query-Reply message
has to encode the current hop in the ER-TLV
- Q4 : reserved for congestion status; < format - TBD >
- Q5 : query the round trip delay; if set, the LSR should fill in
the link delay information if available; < format - TBD >
- Q6 : query which LSPs along the path are merging points; if set,
the LSR that receives the Query message has to encode
if it is a merging point; the encoding is done in the
Query Merge flags TLV.
- Q8 : if set, the ingress requests partial query-replies;
Paraschiv, et. al. [Page 14]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
7.1. Query Label TLV
The Query Label TLV is used to encode the labels used along the path
which is queried.
The format for the Query Label 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Query Label TLV (0x0841)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized Label TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized Label TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Generalized Label TLV is used to encode labels along the path. Please
refer to [OPTICAL reference] for more information on the Generalized
Label TLV encoding. If the Q2 flag is set, every LSR has to encode
the out-label corresponding to the queried LSP. In the Query Label
TLV, labels are organized as a last-in-fist-out stack (the first
label in TLV is considered the top). They should be encoded in the
same order as the hops and the merge flags.
Note: The Query Label TLV could use the Label TLV which is defined in
LDP draft. The same note applies to the Label TLV that encodes the
label which is queried.
7.2. Query Merge Flags TLV
The Query Merge Flags TLV is used to encode the information about
which LSRs along the path the queried LSP is being merged into.
Paraschiv, et. al. [Page 15]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
The format for the Query Label 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Merge Flags TLV (0x0842) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of merge flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Merge flags | | | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Query Merge Flags TLV has 4 bytes field to store the number of
merge flags. This number is equal to the number of LSRs which are
traversed by the Query-Reply Message. Each 2 bits in the Merge flags
field represents the merge info for an LSR. The bit is set to 1 if
the LSR does not do merge for the queried LSP and is set to 2
otherwise. If the LSR want to hide the merging information, it has to
set the merging flags to 0. The length is going to be rounded up to
the next byte. Every LSR which is asked to encode the merging info
into this TLV has to update the Number of merge flags and to set its
corresponding bits accordingly.
7.3. Label TLV
The Label TLV is used to encode the label stack of the labels which
are queried (along the queried LSP).
The format for the Query Label 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Label TLV (0x0843)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized Label TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized Label TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Paraschiv, et. al. [Page 16]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
The Label TLV is a stack of Generalized Labels. The top of the stack
is in the right octets of the TLV encoding. The Label TLV has to be
updated every time the Query message is processed by an LSR. The
encoding of the labels should follow the last-in-first-out stack
model.
Generalized Label TLV is used to encode labels. Please refer to
[OPTICAL reference] for more information on the Generalized Label TLV
encoding.
Note: The Label TLV could use the Label TLV which is defined in LDP
draft.
8. Acknowledgments
The authors would like to acknowledge the careful review and comments
of Jean-Pierre Coupal, Steve Hamilton, Don Fedyk and Gregory Wright.
9. References
[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
draft-ietf-mpls-cr-ldp-03.txt, October 1999
[LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-07.txt,
May 2000.
[RSVP-RR] Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini
S., "RSVP Refresh Overhead Reduction Extensions", draft-ietf-rsvp-
refresh-reduct-04.txt.
[CR-LDP] Peter Ashwood-Smith et al., "Improving Topology Data Base
Accuracy with LSP Feedback", draft-ietf-mpls-te-feed-01.txt
Ashwood-Smith P., Berger L., "Generalized MPLS-Signaling Functional
Description" draft-ashwood-generalized-mpls-signaling-00.txt
Paraschiv, et. al. [Page 17]
Internet Draft draft-ietf-mpls-lsp-query-00.txt October 2000
10. Author's Addresses
Peter Ashwood-Smith Antonela Paraschiv
Nortel Networks Corp. Nortel Networks Corp.
P.O. Box 3511 Station C, 600 Technology Park Drive
Ottawa, ON K1Y 4H7 Billerica, MA 01821
Canada USA
Phone: +1 613-763-4534 phone: +1 978-288-6136
petera@nortelnetworks.com antonela@nortelnetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Paraschiv, et. al. [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-22 18:10:52 |