[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09                                 
Network Working Group                                    P. Ashwood-Smih
Internet Draft                                              A. Paraschiv
Expiration Date: August 2003                             Nortel Networks

                                                           February 2003


Multi Protocol Label Switching Label Distribution Protocol Query Message Description


                    draft-ietf-mpls-lsp-query-06.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
   Label Distribution Protocol (LDP) messages: Query Message, 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).  A Lable Edge Router (LER) sends a Query
   message when it needs to find out information about a Label Switched
   Path (LSP). The Query message is sent for an established LSP.  The
   Query message can be used for LDP LSPs as well as for Constraint-
   Based Label Switched Paths (CR-LSPs).  The queried data is encoded
   into the Query-Reply messages.









Paraschiv, et. al.                                              [Page 1]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003




Contents

    1    Introduction  .............................................   3
    2    Specification  ............................................   3
    3    Overview  .................................................   3
    3.1  LDP Overview  .............................................   3
    3.2  CR-LDP Overview  ..........................................   4
    4    LDP Message Structure Overview  ...........................   4
    5    LSRs with constraints in handling the query messages  .....   5
    5.1  LSR does not support the query messages  ..................   6
    5.2  LSR cannot share any information  .........................   6
    5.3  LSR cannot share some of the queried information   ........   6
    5.4  LSR can share the queried information   ...................   7
    6    Query Message  ............................................   7
    6.1  Query Message encoding     ................................   8
    6.2  Query Message Procedures  .................................   9
    7    Reply Messages   ..........................................  10
    7.1  Query-Reply Message encoding     ..........................  11
    7.2  Query-Reply Message Procedures  ...........................  12
    7.3  Partial Query-Reply Message encoding     ..................  13
    7.4  Partial Query-Reply Message Procedures  ...................  13
    8    Query TLVs  ...............................................  14
    8.1  Query Label TLV  ..........................................  15
    8.2  Query Merge Flags TLV  ....................................  16
    8.3  Status code summary   .....................................  17
    9    Security Considerations  ..................................  17
   10    IANA Considerations  ......................................  17
   10.1  Message Type Space Extension  .............................  17
   10.2  TLV Type Name Space Extension  ............................  17
   10.3  Status Code Space Extension  ..............................  18
   11    Acknowledgments  ..........................................  18
   12    Normative References  .....................................  18
   13    Author's Addresses  .......................................  19
















Paraschiv, et. al.                                              [Page 2]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


   Changes from previous version:

   o  Updated IANA section.

   [Editor's note: This section has to be removed prior to publication as an RFC.]



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 memo describes the query
   mechanism for an LSP or CR-LSP. It specifies procedures and encodings
   for the new messages added for the query mechanism.

   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

   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. Specification

   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 [RFC2119].


3. Overview

3.1. LDP Overview

   Label Distribution Protocol (LDP) defined in [4] 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



Paraschiv, et. al.                                              [Page 3]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


   which packets are mapped to that LSP.


3.2. CR-LDP Overview

   As described in CR-LDP [1], Constraint Base Routing offers the
   opportunity to extend the information used to setup paths beyond what
   is available from the routing protocol. For instance, an LSP can be
   setup based on explicit route constraints, QoS constraints, and other
   constraints.



4. LDP Message Structure Overview

   The LDP message format is specified in the LDP Specification [4]. 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.

   Message Type
      Identifies the type of message

   Message Length



Paraschiv, et. al.                                              [Page 4]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


      Specifies the cumulative length in octets of the Message ID,
      Mandatory Parameters, and Optional Parameters.

   Message ID
      32-bit value used to identify this message.  It is 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 MessageId 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.


5. 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.

   This memo provides flexibility to handle each of the above cases.






Paraschiv, et. al.                                              [Page 5]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


5.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 therefore honors the U bit.


5.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 Section 7.2 of this memo -
   Query Merge Flags TLV ).


5.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 Section 7.2 of this memo -
   Query Merge Flags TLV).












Paraschiv, et. al.                                              [Page 6]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


5.4. LSR can share the queried information

   In this case, the LSR's behavior has to follow the query and replies
   procedures described in the following sections of this memo.

   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.



6. 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.
   This memo currently describes the procedures for the cases when the
   Query Message is initiated by the ingress LER.  Additional procedures
   may be added in the future for the query message when issued from an
   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" [2])
           - anything that is needed in the future and can be computed and
             encoded in a TLV.


   The queried information is encoded in the Query-Reply message which
   is sent back upstream, as a response to the Query message.



Paraschiv, et. al.                                              [Page 7]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


6.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 type TBD IANA |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Query Label TLV                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Query TLV                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Hop Count TLV                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Optional Parameters                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Message ID
      32-bit value used to identify this message.

   Query Label TLV
      The label associated to the LSP which is queried. This TLV is a
      list of Generalized Label TLVs [3].  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
      7.1 of this memo - Query Label TLV - for more information on Label
      TLV encoding.

   Query TLV
      What to query. See Section 7 of this memo - 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 default 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; a Notification
      signaling Loop Detection should be sent in reply to the sender of
      the message. See [4] for Hop Count TLV encoding.



Paraschiv, et. al.                                              [Page 8]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


   Optional Parameters
      This variable length field contains 0 or more parameters, each
      encoded as a TLV.

               Optional Parameter     Length       Value

               ER      TLV            var          See [1]
               LSPID   TLV            var          See [1]
               FEC     TLV            var          See [4]

   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.

   FEC TLV is used when PHP is in use, for LDP.

   LSPID TLV is used when PHP is in use, for CR-LDP.

   For more details on the FEC or LSPID usage, please refer to the Query
   Message Procedures below.



6.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 could carry is the list of hops. This way, each
   node along the path can have a complete route from source to
   destination.  This is useful for network management. Please note that
   this parameter is optional. If the Query message does not contain the
   ER TLV, it should be propagated by LSRs along the path without the ER
   TLV.

   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 with "No LSP to query"
   status. 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 Query 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



Paraschiv, et. al.                                              [Page 9]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


   both the previous label and the tunnel's label. The Query 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
   along the path which information is being queried and allows
   intermediate LSRs to piggy back their own queried information on the
   Query reply message.

   The initiator of a Query reply might not receive a response back. In
   this case, it is the initiator's responsibility to decide if and when
   to retry.

   If PHP is in use, the Query Message sent from the PHP to the
   destination node needs to carry the FEC (for LDP) or LSPID (for CR-
   LDP). This information is required because the label between the PHP
   and the destination is a special label and the destination cannot
   uniquely identify the queried LSP just by using the label value. If
   the PHP does not encode the FEC or the LSPID, the destination node
   should reply with a notification message with "Ambiguous label
   value".



7. Reply Messages

   These messages are propagated upstream.  There are two types of reply
   messages:

           - Query-Reply message (final reply)
           - Partial Query-Reply message.

   The Reply messages carry the queried information upstream. A Query-
   Reply message is sent in response to a Query message. The ingress
   which initiated the Query message is interested to gather the
   information from all the nodes along the queried LSP.  However, there
   are situations in which the Query message does not reach the end
   point of the queried LSP. 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.  If the
   Reply message is full, TCP will take care of it by segmenting and
   re-assembling the message.




Paraschiv, et. al.                                             [Page 10]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


   Both reply messages are described in the following sections.



7.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 Type TBD IANA  |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Query TLV                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     MessageId TLV                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Optional Parameters                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Message ID
      32-bit value used to identify this message.

   Query TLV
      What is to be queried. See Section 7 of this memo - Query TLV -
      for encoding.

   MessageId TLV
      The value of this parameter is the message id of the corresponding
      Query message.

   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 [1]
               Query Label TLV        var          See Query Label TLV section
               IPV4/6 specified link feedback TLV  See [2]
               Query Merge Flags TLV   var         See Query Merge Flags TLV
                                                   section



Paraschiv, et. al.                                             [Page 11]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


   The TLV types are defined in CR-LDP [1] and LDP [4]. They are:

           - IPV4/6 specified link feedback TLV
           - ER TLV
           - Generalized Label TLV (used in the Query Label TLV encoding)
           - Hop Count TLV.

   The IPV4/6 specified link feedback TLV is used when the Q1 flag from
   the Query TLV is set. It is used to encode the bandwidth information.
   For more information on query flags, Q1, Q2, Q3 and Q4, 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
   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 list of pairs of bits. 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 Q4 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, Q4 is set when Q2 set and/or Q3 set.

   For more information for the TLV encodings of the TLVs which are
   used, please see [1], [4] and [2].



7.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 with "No LSP to
   query" status.

   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



Paraschiv, et. al.                                             [Page 12]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


   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, towards the ingress. Every LSR across the LSP has
   to encode its information according to what query flags are set.



7.3. Partial Query-Reply Message encoding

   The Partial Query-Reply message is initiated by 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 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|Partial Query-Reply TBD IANA |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Query TLV                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     MessageId TLV                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Optional Parameters                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



7.4. Partial Query-Reply Message Procedures

   The procedures are similar to the Query-Reply's procedures.  Upon
   receiving a Query message, an 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



Paraschiv, et. al.                                             [Page 13]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


   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).




8. 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  Type TBD IANA |      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Query  Flags  |            Reserved                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Query Flags can be set according to what the Query  is  used  for.  A
   query flag is set when it is 1.

      +--+--+--+--+--+--+--+--+
      |Q8|Reserved|Q4|Q3|Q2|Q1|
      +--+--+--+--+--+--+--+--+

   They can be:














Paraschiv, et. al.                                             [Page 14]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


           - 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 : 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; each LSR
                  along the path is signaled to send a Partial Query Reply.

   The reserved bits need to be set to zero on transmission and must be
   ignored on receipt. They might be used in the future to signal other
   types of queried information. The Query Flags can only be defined by
   updating this memo.



8.1. Query Label TLV

   The Query Label TLV is used to encode the labels used along the path
   which is queried.

   Note: Query Label TLV is used in both Query and Query Reply. It is a
   required parameter in the Query message and it is an optional
   parameter in Query Reply message. When being used in the Query
   message, it carries the label or stack of labels which are being
   followed and queried. When being used in the Query Reply message, it
   carries the list of labels which make up the queried path.

   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 TBD IANA  |      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Generalized Label TLV 1                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Generalized Label TLV n                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Paraschiv, et. al.                                             [Page 15]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


   Generalized Label TLV is used to encode labels along the path. Please
   refer to [3] 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.


8.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.

   The format for the Query Merge Flags 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 TBD IANA  |      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.  The Merge flags field contains
   the merge information. It is a variable length field which is rounded
   up to the next byte. Each pair of bits in the Merge flags field
   carries the merge information for one LSR. The valid values for the
   merge bits for an LSR are:

           01 - LSR does not do merge for the queried LSP
           10 - LSR does merge for the queried LSP
           00 - LSR cannot share the merge information.

   Every LSR which is asked to encode the merging info has to update the
   Number of merge flags and to set its corresponding bits accordingly.







Paraschiv, et. al.                                             [Page 16]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


8.3. Status code summary

       Status Code           E   Status Data   Section Title

       No LSP to query       1   TBD IANA      "Query Message Procedures..."
       Ambiguous label value 1   TBD IANA      "Query Message Procedures..."



9. Security Considerations

   The Query mechanism inherits the same security mechanism described in
   Section 4.0 of [4].  The Query mechanism provides an additional
   security measure for cases when a node cannot share the queried
   information. Such nodes have the option of hiding their information,
   if their configuration requires it. Please refer to Section 4 of this
   memo - "Behavior of LSRs with constraints in handling the query
   messages" - for more details.



10. IANA Considerations

   RFC 3036 [4] defines several name spaces including the Message Type
   Name Space, the TLV Type Name Space, and the Status Code Name Space.
   This document makes the following assignments within those spaces.


10.1. Message Type Space Extension

   The message types for Query Message, Query-Reply Message and Partial
   Query-Reply Message are as follows:

            Message                                           Type
            --------------------------------------         ----------
            Query Message                                   TBD IANA
            Query Reply Message                             TBD IANA
            Partial Query Reply Message                     TBD IANA


10.2. TLV Type Name Space Extension

   The TLV types for Query TLV, Query Label TLV and Query Merge Flags
   TLV are as follows:







Paraschiv, et. al.                                             [Page 17]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003


            TLV                                               Type
            --------------------------------------         ----------
            Query TLV                                       TBD IANA
            Query Label TLV                                 TBD IANA
            Query Merge Flags TLV                           TBD IANA


10.3. Status Code Space Extension

   The Status codes "No LSP to query" and "Ambiguous label value" are as
   follows:

            Status Code                                       Type
            --------------------------------------         ----------
            No LSP to query                                 TBD IANA
            Ambiguous label value                           TBD IANA


11. Acknowledgments

   The authors would like to acknowledge the careful review and comments
   of Jean-Pierre Coupal, Steve Hamilton, Don Fedyk, Gregory Wright and
   Adrian Farrel.



12. Normative References

[1]    B. Jamoussi et al., "Constraint-Based LSP Setup using LDP", RFC
3212, January 2002

[2]    Peter Ashwood-Smith et al., "Improving Topology Data Base
Accuracy with LSP Feedback", Work in Progress, draft-ietf-mpls-te-feed-
03.txt.

[3]    Ashwood-Smith P., Berger L., "Generalized MPLS - Signaling
Functional Description", Work in Progress, draft-ietf-mpls-generalized-
signaling-07.txt.

[4]    Andersson et al., "LDP Specification", RFC 3036, January 2001.











Paraschiv, et. al.                                             [Page 18]


Internet Draft      draft-ietf-mpls-lsp-query-06.txt       February 2003



13. 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 (2002). 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 19]