[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                           P Doolan
Internet Draft                                             cisco Systems
Expiration Date: November 1997
                                                                 B Davie
                                                           cisco Systems

                                                                  D Katz
                                                        Juniper Networks

                                                               Y Rekhter
                                                           cisco Systems

                                                                 E Rosen
                                                           cisco Systems

                                                                May 1997


                       Tag Distribution Protocol


                      draft-doolan-tdp-spec-01.txt

Status of this Memo

   This document is an Internet-Draft.  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 learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).











Doolan, et al.                                                  [Page 1]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


1. Abstract

   An overview of a  tag switching architecture is provided in
   [Rekhter].  This document defines the Tag Distribution Protocol (TDP)
   referred to in [Rekhter].

   TDP is a two party protocol that runs over a connection oriented
   transport layer with guaranteed sequential delivery.  Tag Switching
   Routers use TDP to communicate tag binding information to their
   peers. TDP supports multiple network layer protocols including but
   not limited to IPv4, IPv6, IPX and AppleTalk.

   We define here the PDUs and operational procedures for this TDP and
   specify its transport requirements. We also define aspects of the
   protocol that are specific to the case where it is run over an ATM
   datalink.



Contents

         Status of this Memo  ......................................   1
    1    Abstract  .................................................   2
    2    Protocol Overview  ........................................   3
    2.1  TDP and Tagswitching over ATM  ............................   4
    3    State machines  ...........................................   4
    3.1  TDP state transition table  ...............................   4
    3.2  TDP state transition diagram  .............................   6
    3.3  Transport connections  ....................................   7
    3.4  Timeout  ..................................................   7
    4    Protocol Data Units (PDUs)  ...............................   7
    4.1  TDP Fixed Header  .........................................   7
    4.2  TDP TLVs  .................................................   8
    4.3  Example TDP PDU  ..........................................  10
    4.4  PIEs defined in V1 of TDP  ................................  10
    4.5  TDP_PIE_OPEN  .............................................  11
    4.6  TDP_PIE_BIND  .............................................  18
    4.7  TDP_PIE_REQUEST_BIND  .....................................  24
    4.8  TDP_PIE_WITHDRAW_BIND  ....................................  32
    4.9  TDP_PIE_RELEASE_BIND  .....................................  34
    4.10 TDP_PIE_KEEP_ALIVE  .......................................  35
    4.11 TDP_PIE_NOTIFICATION  .....................................  36
    5    Intellectual Property Considerations  .....................  39
    6    Acknowledgments  ..........................................  39
    7    References  ...............................................  39
    8    Author Information  .......................................  40





Doolan, et al.                                                  [Page 2]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


2. Protocol Overview

   A tag switching architecture is described in [Rekhter]. As explained
   in that document Tag Switching Routers (TSRs) create tag bindings,
   and then distribute the tag binding information among other TSRs.

   TDP provides the means for TSRs to distribute, request, and release
   tag binding information for multiple network layer protocols. TDP
   also provides means to open, monitor and close TDP sessions and to
   indicate errors that occur during those sessions.

   TDP is a two party protocol that requires a connection oriented
   transport layer with guaranteed sequential delivery. We use TCP as
   the transport for TDP.

   A TSR that wishes to exchange tag bindings with another opens a TCP
   connection to the TDP port (TBD) on that other TSR. Once the TCP
   connection has been established then the TSRs exchange TDP PDUs that
   encode tag binding information. TDP is symmetrical in that once the
   TCP connection has been opened the peer TSRs may each send and
   receive TDP PDUs at will.

   A single TSR may have TDP sessions with multiple other TSRs. Each of
   these sessions is completely independent of the others. Multiple TDP
   sessions may exist between any given pair of TSRs. Each of these
   sessions is completely independent of the others. TDP sessions are
   identified by the 'TDP Identifier' field in the TDP header (see
   below).

   TDP does not require any  keepalive notification from the transport,
   but implements its own keepalive timer. The usage is straightforward:
   peers must communicate within the period specified by the timer. Each
   time a TDP peer receives a TDP PDU it resets the timer. If the timer
   expires some number of times without reception of a TDP PDU from the
   remote system the TDP closes the session with its peer.

   When a TSR determines that it lost a TDP session with another TSR, if
   the TSR has any tag bindings that were created as a result of
   receiving tag binding requests from the peer, the TSR may destroy
   these bindings (and deallocate tags associated with these binding).

   When a TSR determines that it lost a TDP session with another TSR,
   the TSR shall no longer use the binding information it received from
   the other TSR.

   The procedures that govern when other components in a TSR invoke
   services from TDP and how a TSR maintains its TIBs are beyond the
   scope of this document.



Doolan, et al.                                                  [Page 3]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


   The use of TDP does not preclude the use of other mechanisms to
   distribute tag binding information.

2.1. TDP and Tagswitching over ATM

   The tagswitching architecture [Rekhter] describes application of tag
   switching to ATM, [Davie] provides more details and describes  a
   number of features of TDP required specifically to support this ATM
   case. We describe control circuit useage and encapsulation here.  The
   sections on TDP_PIE_BIND and TDP_PIE_REQUEST_BIND describe how 'Hop
   Count' referred to in [Davie] is carried.


2.1.1. Default VPI/VCI

   By default the TDP connection between two ATM-TSRs uses VPI/VCI 0/32.
   The default TDP connection uses the LLC/SNAP encapsulation defined in
   RFC1483 [Heinanen]. This TDP VC may be used to exchange other
   LLC/SNAP encapsulated traffic. In particular the TDP VC might be used
   to carry  Network Layer routing information. There are circumstances
   (see ATM_TAG_RANGE) when this VC is also used to carry data traffic.

   TDP provides means to advertise the range of, and negotiate the
   encapsulation used on, the data VCs. See the section on TDP_PIE_OPEN
   for further details.

   Cooperating TSRs may agree to use VPI/VCI other than 0/32 as the TDP
   VC, how they do this (management) is outside the scope of this
   document.


3. State machines

   We describe the TDP's  behavior in terms of a state machine. We
   define the TDP state machine to have four possible states and present
   the behavior as a state transition table and diagram.

3.1. TDP state transition table



           STATE           EVENT                           NEW STATE

                           Initialization                  INITIALIZED

           INITIALIZED     Sent     TDP_PIE_OPEN           OPENSENT
                           Received TDP_PIE_OPEN           OPENREC




Doolan, et al.                                                  [Page 4]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


           OPENREC         Received TDP_PIE_KEEP_ALIVE     OPERATIONAL
                           Received Any other TDP PDU      INITIALIZED

           OPENSENT        Received TDP_PIE_OPEN   &
                           Transmit TDP_PIE_KEEP_ALIVE     OPENREC
                           Received Any other TDP PDU      INITIALIZED
                           Sent     TDP_PIE_NOTIFICATION   INITIALIZED

           OPERATIONAL     Rx/Tx    TDP_PIE_NOTIFICATION
                                    with CLOSING parameter INITIALIZED
                           Other    TDP PDUs               OPERATIONAL
                           Timeout                         INITIALIZED







































Doolan, et al.                                                  [Page 5]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


3.2. TDP state transition diagram


                                         ---
                                        |   | All TDP PIEs except PIE_OPEN
                                        V   |
                                 ---------------
                 Rx Ao PDU       |              |<--------------------------
                 Tx NOTIFICATION |              |                          |
                  -------------->| INITIALIZED  |                          |
                 |             --|              |---                       |
                 |            |   -------------    |                       |
                 |            |                    |                       |
                 |            |Rx PIE_OPEN &       |Tx PIE_OPEN            |
                 |            |(Tx OPEN            |                       |
                 |            |Tx KEEP_ALIVE)      |                       |
                 |            V                    V                       |
                 |      ---------             ----------                   |
                 |     |         |           |          |                  |
                  -----| OPENREC |           | OPENSENT | ---------------- |
                  -----|         |           |          | Rx Ao PDU        ^
                 |      ---------             ----------  Tx NOTIFICATION  |
                 |            ^                 |                          |
                 |            |Rx PIE_OPEN & Tx |                          |
                 |            |KEEP_ALIVE       |                          |
                 |              ----------------                           |
                 |Rx                                                       |
                 |PIE_KEEP_ALIVE                                           |
                 |         ------------                                    |
                  ------->|            |                                   |
                          | OPERATIONAL|                                   |
                          |            |-----------------------------------
                           ------------      R/Tx NOTIFICATION  with CLOSE
                       All other | ^         or TIMEOUT
                        TDP PDUs | |
                                 |_|















Doolan, et al.                                                  [Page 6]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


3.3. Transport connections

   A TSR that implements TDP opens a TCP connection to a peer TSR. Once
   open, and regardless of which TSR opened it, the TCP connection is
   used bidirectionally. That is there is only one TCP 'connection' used
   for a TDP session between two TSRs. TDP uses TCP port (TBD).


3.4. Timeout

   Timeout in the state transition table and diagram indicates that the
   keep alive timer set to HOLD_TIME has expired. See TDP_PIE_OPEN for a
   discussion of this mechanism.


4. Protocol Data Units (PDUs)

   TDP PDUs are variable length and consist of a fixed header and one or
   more Protocol Information Elements (PIE) each with a Type Length
   Value (TLV) structure. Within a single PIE TLVs may be nested to an
   arbitrary depth.

   A single TDP PDU may contain multiple PIEs.  The maximum TDP PDU size
   is 4096 octets.


4.1. TDP Fixed Header

   The fixed header of the TDP PDU 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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |  Version                      |         LENGTH                |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                         TDP Identifier                        |
           +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                               |          Res                  |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Version:

        This two octet unsigned integer contains the version number of
        the protocol.  A TDP version number must lie in the range  0x01
        <= Version <= 0xFF. This version of the TDP specification speci-
        fies protocol Version = 1.




Doolan, et al.                                                  [Page 7]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997




   LENGTH:

     This two octet integer specifies the length in octets of the data
     portion of the PDU. LENGTH is set to the length of the PDU in
     octets minus four.



   TDP Identifier:

     Six octet unsigned integer containing a unique identifier for the
     TSR that generated the PDU. The value of this Identifier is deter-
     mined  on startup. The first four octets encode an IP address
     assigned to the TSR. The last two octets represent the 'instance'
     of TDP on the TSR. A TSR with only one active TDP session would
     supply the value zero in this field.



   Res:

     This field is reserved. It must be set to zero on transmission and
     must be ignored on receipt.

4.2. TDP TLVs

   The TDP fixed header frames Protocol  Information Elements (PIEs)
   that have a Type Length Value (TLV) structure.

   In this protocol TYPE  is a 16  bit integer value that encodes how
   the VALUE field is to be interpreted. Within a single PIE TLVs may be
   nested to an arbitrary depth. A TDP must silently discard TLVs that
   it does not recognize.

   LENGTH is an unsigned  16 bit integer value that encodes the length
   of the VALUE field in octets. LENGTH is set to the length of the
   whole TLV in octets minus four. A LENGTH of zero indicates that there
   is no value field present.

   VALUE is an octet string of length LENGTH octets that encodes infor-
   mation the semantics of which are indicated by the TYPE field.

   A single TLV has the following format:






Doolan, et al.                                                  [Page 8]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997



            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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     TYPE                      |      LENGTH                   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |          Value   -- length as given by 'LENGTH' field
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |..............
           +-+-+-+-+-+-+-+-+









































Doolan, et al.                                                  [Page 9]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


4.3. Example TDP PDU

   A complete TDP PDU containing two PIEs having 4 and 5 octets of Value
   field respectively would  have the following structure:

            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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |  Version                      |         LENGTH = 25           |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                         TDP Identifier                        |
           +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                               |          Res                  |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     TYPE                      |      LENGTH = 4               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                         Value                                 |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     TYPE                      |      LENGTH = 5               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                         Value
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           |
           +-+-+-+-+-+-+-+-+


4.4. PIEs defined in V1 of TDP

   The following PIEs are defined for this version of the protocol. They
   are described in the sections that follow


                   Type 0x100 TDP_PIE_OPEN
                   Type 0x200 TDP_PIE_BIND
                   Type 0x300 TDP_PIE_REQUEST_BIND
                   Type 0x400 TDP_PIE_WITHDRAW_BIND
                   Type 0x500 TDP_PIE_KEEP_ALIVE
                   Type 0x600 TDP_PIE_NOTIFICATION
                   Type 0x700 TDP_PIE_RELEASE_BIND
                   Type 0x800 Unassigned
                   ..........
                   Type 0xFF00

   Each of these PIEs may have optional TLV encoded parameters.







Doolan, et al.                                                 [Page 10]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


4.5. TDP_PIE_OPEN

   TDP_PIE_OPEN is the first PIE sent by a TSR initiating a TDP session
   to its peer. It is sent immediately after the TCP connection has been
   opened. The TSR receiving a TDP_PIE_OPEN responds either with a
   TDP_PIE_KEEPALIVE or with a TDP_PIE_NOTIFICATION.

4.5.1. Initiating a TDP session

   A TSR initiating a TDP session sets the TDP_OPEN_PIE's fields as
   described below, issues a PDU containing it to the target peer, the
   TDP state machine transitions to the OPENSENT state.

   While in the OPENSENT state a TSR takes the following actions:

     If it receives an 'acceptable' TDP_PIE_OPEN then TSR sends a
     TDP_PIE_KEEPALIVE and the TDP state machine transitions to the
     OPEN_REC state.

     Receipt of any other PDU is an error and results in sending a
     TDP_PIE_NOTIFICATION indicating a bad open and transition to the
     INITIALIZED state.


4.5.2. Passive OPEN

   A TSR in the INITIALIZED state that receives a TDP_PIE_OPEN behaves
   as follows:

     If it can  support the version of the protocol proposed by the TSR
     that issued the TDP_PIE_OPEN then it sets Version in all its subse-
     quent communication with that TSR to the value proposed in Prop Ver
     and obeys the rules specified for that version of the protocol.

     TSR sends a PDU containing a TDP_PIE_OPEN PIE to the TSR that ini-
     tiated the TDP session.

     TSR  sends a PDU containing a TDP_PIE_KEEPALIVE PIE to the TSR that
     initiated the TDP session.

     The TDP state machine transitions to the OPEN_REC state

     If the TSR  cannot support the version of the protocol proposed in
     the TDP_PIE_OPEN then it sends a TDP_PIE_NOTIFICATION PDU that
     informs the TSR which generated the PIE_OPEN of the version(s) it
     can support. The TDP state machine transitions to the INITIALIZED
     state. See below under errors for more details.




Doolan, et al.                                                 [Page 11]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


4.5.3. OPENREC state

   When in the OPENREC state a TSR takes the following actions:

     If a TDP_PIE_KEEPALIVE is received then it transitions to the
     OPERATIONAL state.

     Receipt of any other PDU causes the generation of a
     TDP_PIE_NOTIFICATION and transition to the INITIALIZED state.




   The TDP_PIE_OPEN has 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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     TYPE (0x100)              |      LENGTH                   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |        Prop Ver               |      Hold Time                |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                       Optional Parameters                     |
           |                       (Variable  Length)                      |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TYPE:

     Type field as described above. Set to 0x100 for TDP_PIE_OPEN.



   LENGTH:

     Length in octets of the  value field of this PIE. LENGTH  is set to
     the length of the whole PIE in octets minus four.



   Prop Ver:

     The Version of the TDP that the TSR that generated this PDU pro-
     poses be used for this TDP session once it is established.  Note
     that the session is not established until the TSR that issues a
     TDP_PIE_OPEN receives a TDP_PIE_OPEN in response.






Doolan, et al.                                                 [Page 12]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997




   Hold Time:

     Two octet unsigned non zero integer that indicates the number of
     seconds that the peer initiating the connection proposes for the
     value of the Hold Timer.  Upon receipt of a PDU with PIE
     TDP_PIE_OPEN , a TDP peer  MUST calculate the value of the Hold
     Timer by using the smaller of its configured HOLD_TIME and the
     HOLD_TIME received in the PDU.  The value chosen for HOLD_TIME
     indicates the maximum number of seconds that may elapse between the
     receipt of successive PDUs from the TDP peer. The Hold Timer is
     reset each time a TDP_PDU arrives.  If the timer expires without
     the arrival of a TDP_PDU then a TDP_NOTIFICATION with the optional
     parameter CLOSING is sent.



   Optional Parameters:

     This variable length field contains zero or more optional PIEs sup-
     plied in TLV structures.

             +-----------------------+----------+--------+-----------+
             | OPTIONAL PARAMETER    | Type     | Length | Value     |
             +-----------------------+----------+--------+-----------+
             | DOWNSTREAM_ON_DEMAND  | 0x101    |   0    |   0       |
             +-----------------------+----------+--------+-----------+
             | ATM_TAG_RANGE         | 0x102    |Variable|See below  |
             +-----------------------+----------+--------+-----------+
             | ATM_ENCAPSULATION     | 0x103    |   0    |   0       |
             +-----------------------+----------+--------+-----------+


          DOWNSTREAM_ON_DEMAND:

          A TSR may supply this optional parameter to indicate that it
          wishes to use downstream tag allocation on demand. When either
          of the peers in a TDP session indicates that it requires down-
          stream allocation on demand then both shall use that mechan-
          ism. TSRs operating in downstream on demand provide bindings
          only in response to TDP_PIE_REQUEST_BINDs.

          ATM_TAG_RANGE:

          An ATM-TSR supplies this parameter to indicate to its ATM peer
          the range of VCIs that it can use as tags (on this VP). An ATM
          TSR, when satisfying a TDP_PIE_BIND_REQUEST, may only generate



Doolan, et al.                                                 [Page 13]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


          VCI/prefix bindings, ie bindings of BLIST_TYPE 6, containing
          VCI values from the range communicated to it using this
          optional parameter.

          If an ATM-TSR is unable to generate a BLIST_TYPE 6 binding
          within the constraints imposed by ATM_TAG_RANGE it may gen-
          erate a binding of BLIST_TYPE 2.[In that case the TSR receiv-
          ing the binding sends data traffic on the default TDP VCI but
          tagged with the BLIST_TYPE 2 tag]

          The value for this optional parameter is a list of entries of
          the following form:

              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
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |               VPI                                             |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |               VCI Upper range bound                           |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |               VCI Lower range bound                           |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


          VPI:

          32 bit unsigned integer encoding the VPI to the which the fol-
          lowing VCI range bounds apply.

          VCI Upper range bound:

          32 bit unsigned integer encoding the upper bound of a block of
          VCIs that the ATM_TSR originating the TDP_PIE_OPEN is making
          available as tags. VCI values between and including Upper and
          Lower range bound may be used as tags.

          VCI Lower range bound:

          32 bit unsigned integer encoding the lower bound of a block of
          VCIs that the ATM_TSR originating the TDP_PIE_OPEN is making
          available as tags. VCI values between and including Upper and
          Lower range bound may be used as tags.

          The number of entries may be deduced from the value in the
          Length field. VCI tags may be allocated from the range indi-
          cated by the upper/lower values inclusive of those values.
          There must be at least one entry. There may be more than
          one.There may be more than one entry with the same VPI value.



Doolan, et al.                                                 [Page 14]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


          ATM_NULL_ENCAPSULATION:

          An ATM-TSR supplies this parameter to indicate that it sup-
          ports the null encapsulation of RFC1483 [Heinanen] for its
          data VCs. In this case IP packets are carried directly inside
          AAL5 frames. This option is only used by an ATM-TSR that it is
          configured to support a single level of tagging. See [Davie]
          for more details.

          An ATM-TSR that cannot support this option will generate the
          error TDP_WRONG_ENCAPS.




4.5.4. Errors

   All Errors generated by the receipt of a TDP_PIE_OPEN are reported by
   issuing a TDP_PIE_NOTIFICATION.  The value field of the PIE contains
   one or more TLVs describing individual errors with more precision.

           +--------------------------+----------+--------+------------+
           | Error                    | Type     | Length | Value      |
           +--------------------------+----------+--------+------------+
           | TDP_OPEN_UNSUPPORTED_VER | 0x1F0    |   Var  | See below  |
           +--------------------------+----------+--------+------------+
           | TDP_BAD_OPEN             | 0x1F1    |   0    |   0        |
           +--------------------------+----------+--------+------------+
           | TDP_WRONG_ENCAPS         | 0x1F2    |   0    |   0        |
           +--------------------------+----------+--------+------------+


4.5.4.1. TDP_OPEN_UNSUPPORTED_VER:

   This error is issued to indicate to the TSR that generated the
   TDP_PIE_OPEN that this TSR does not support the version of TDP pro-
   posed in 'Prop Ver' in the PIE_OPEN. TDP_OPEN_UNSUPPORTED_VER reports
   the version(s) of the protocol that this TSR does support.

   A TSR that receives this error may choose to reissue the TDP_PIE_OPEN
   specifying a version of the protocol that the target systems has
   indicated it can support. If a TSR is to take this action it should
   not close (and reopen) the TCP connection before so doing but should
   leave the  connection 'up' during the negotitation process.

   A TSR that generates this error should anticipate that the other sys-
   tem may reissue the TDP_PIE_OPEN and should wait at least
   TRANSPORT_HOLDDOWN seconds (default 30 ) before it closes the TCP



Doolan, et al.                                                 [Page 15]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


   connection. The TRANSPORT_HOLDDOWN  timer is started when a
   TDP_PIE_NOTIFICATION containing TDP_OPEN_UNSUPPORTED_VER is sent and
   is reset on reception of a TDP_PIE_OPEN. These measure are designed
   to stop the version negotiation mechanism 'thrashing' the transport
   setup mechanism.



   TYPE:

     TDP_OPEN_UNSUPPORTED_VER = 0x1F0



   LENGTH:

     Length in octets of the  value field of this PIE. LENGTH  is set to
     the length of the whole PIE in octets minus four.



   VALUE:

     One or more 2 octet integers that encode the Version(s) of the pro-
     tocol that this TSR supports.



   The format of an NOTIFICATION PIE containing TDP_OPEN_UNSUPPORTED_VER
   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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |    TDP_PIE_NOTIFICATION       |      LENGTH                   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |    TDP_OPEN_UNSUPPORTED_VER   |      LENGTH                   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           | Supported version(s) ............
           +-+-+-+-+-+-+-+-+


4.5.4.2. TDP_BAD_OPEN

   This error is issued to indicate failure during the open phase.






Doolan, et al.                                                 [Page 16]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


4.5.4.3. TDP_WRONG_ENCAPS

   This error is used to indicate that an ATM-TSR will not support the
   null encapsulation proposed in the TDP_PIE_OPEN (by the inclusion of
   the option ATM_NULL_ENCAPSULATION).














































Doolan, et al.                                                 [Page 17]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


4.6. TDP_PIE_BIND

   TDP_PIE_BIND is sent from one TSR to another to distribute tag bind-
   ings. Transmission of a TDP_PIE_BIND may occur as a result of some
   local decision or it may be in response to the reception of a
   TDP_REQUEST_BIND.

   This PIE has 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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     TYPE (0x200)              |      LENGTH                   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                Request ID                                     |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           AFAM                |      BLIST_TYPE               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           BLIST_LENGTH        |                               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     BINDING_LIST              |
           |           Variable length list consisting of one or more      |
           |           BLIST entries ....                                  |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                               |
           |                       Optional Parameters                     |
           |                       (Variable  Length)                      |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





   TYPE:

     Type field as described above. Set to 0x200 for TDP_PIE_BIND.



   LENGTH:

     Length in octets of the  value field of this PIE. LENGTH  is set to
     the length of the whole PIE in octets minus four.









Doolan, et al.                                                 [Page 18]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997




   Request ID:

     If this TDP_PIE_BIND is generated in response to a
     TDP_PIE_REQUEST_BIND then TSR places the value of the Request ID
     from that request PIE in this field. For all other TDP_PIE_BINDS
     this field must be set to zero.



   AFAM:

     This 16 bit integer contains a value from ADDRESS FAMILY NUMBERS
     in Assigned Numbers [Reynolds] that encodes the address family that
     the network layer address in the tag bindings in the BINDING_LIST
     is from. This protocol provides support for multiple network
     address families.



   BLIST_TYPE:

     This 16 bit integer contains a value from the table below that
     encodes the format and semantics of the BLIST entries in the
     BINDING_LIST field.

             BLIST_TYPE      BLIST entry format
               0             Null list (see TDP_PIE_WITHDRAW_BIND)
               1             32 bit Upstream assigned
               2             32 bit Downstream assigned
               3             32 bit Multicast Upstream assigned (*,G)
               4             32 bit Multicast Upstream assigned (S,G)
               5             32 bit Upstream assigned VCI tag
               6             32 bit Downstream assigned VCI tag

     The formats are defined below.



   BLIST_LENGTH:

     Two octet unsigned integer that encodes the length of the
     BINDING_LIST







Doolan, et al.                                                 [Page 19]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997




   BINDING_LIST:

     Variable length field consisting of one or more BLIST entries of
     the type indicated by BLIST_TYPE.



   Optional Parameters:

     This variable length field contains zero or more optional PIEs sup-
     plied in TLV structures.

4.6.1. BLIST_TYPE 0

   BLIST_TYPE = 0 indicates that there are no BLIST entries. See
   TDP_PIE_WITHDRAW_BIND for further details.



4.6.2. BLIST_TYPE 1 and 2

   A BLIST_TYPE 1 contains Upstream assigned tags.  A TDP must only
   include tag values in a BLIST_TYPE 1 tag entry that lie between the
   values, inclusive of those values, that the TSR to whom the
   TDP_PIE_BIND is being sent indicated it could support during the OPEN
   phase.

   BLIST entries of type 1 and 2  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
           +-+-+-+-+-+-+-+-+
           |  Precedence   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |       Tag                                                     |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |  Pre Len      |     Prefix  (length variable )
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................




   Precedence

     8 bit unsigned integer containing the precedence with which traffic
     bearing this tag will be serviced by the TSR that issued the



Doolan, et al.                                                 [Page 20]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


     TDP_PIE_BIND. [Note that the precedence is likely to be restricted
     to perhaps three bits of the space reserved here.]



   Tag:

     Tag is a 32 bit unsigned integer encoding the value of the tag.



   Pre Len:

     This one octet unsigned integer contains the length in bits of the
     address prefix that follows.



   Prefix:

     A variable length field containing an address prefix whose length,
     in bits, was specified in the previous (Pre Len) field. A Prefix is
     padded with sufficient trailing zero bits  to cause the end of the
     field to fall on an octet boundary.

4.6.3. BLIST_TYPE 3

   This binding  allows the association of a tag with  the (*,G) shared
   tree.  See [Deering] for a discussion of (*,G) shared trees.

   The (*,G) binding has 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
           +-+-+-+-+-+-+-+-+
           |  Precedence   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |       Tag                                                     |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |       Multicast Group Address G                               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+










Doolan, et al.                                                 [Page 21]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997




   Precedence

     8 bit unsigned integer containing the precedence with which traffic
     bearing this tag will be serviced by the TSR that issued the
     TDP_PIE_BIND. [Note that the precedence is likely to be restricted
     to perhaps three bits of the space reserved here.]



   Tag:

     Tag is a 32 bit unsigned integer encoding the value of the tag.



   Multicast Group Address G:

     Multicast Group Address. The length of this address is network
     layer specific and can be deduced from the value of AFAM. The
     diagram above illustrates a four octet IPv4 address format.


4.6.4. BLIST_TYPE 4

   This binding type  allows association of a tag with a (S,G) source
   rooted tree. See [Deering] for a discussion of (S,G) trees.

   The (S,G) binding has 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
           +-+-+-+-+-+-+-+-+
           |  Precedence   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                       Tag                                     |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                       Source Address S                        |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                       Multicast Group Address G               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+









Doolan, et al.                                                 [Page 22]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997




   Precedence

     8 bit unsigned integer containing the precedence with which traffic
     bearing this tag will be serviced by the TSR that issued the
     TDP_PIE_BIND. [Note that the precedence is likely to be restricted
     to perhaps three bits of the space reserved here.]



   Tag:

     Tag is a 32 bit unsigned integer encoding the value of the tag.



   Source Address S:

     Network Layer address of the  source sending to the G tree. The
     length of this address is network layer specific and can be deduced
     from the value of AFAM. The diagram above illustrates a four octet
     IPv4 address format.



   Multicast Group Address G:

     Network Layer Multicast group address.  The length of this address
     is network layer specific and can be deduced from the value of
     AFAM. The diagram above illustrates a four octet IPv4 address for-
     mat.


4.6.5. BLIST_TYPE 5 and 6

   BLIST entries of type 5 and 6  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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |  Precedence   |      HC       |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |       Tag                                                     |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |  Pre Len      |     Prefix  (length variable )
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................




Doolan, et al.                                                 [Page 23]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997




   Precedence:

     8 bit unsigned integer containing the precedence with which traffic
     bearing this tag will be serviced by the TSR that issued the
     TDP_PIE_BIND. [Note that the precedence is likely to be restricted
     to perhaps three bits of the space reserved here.]



   HC:

     Hop count. See [Davie] for a detailed description.



   Tag:

     Tag is a 32 bit signed integer encoding the value of the tag. (See
     section 2.1).



   Pre Len:

     This one octet unsigned integer contains the length in bits of the
     address prefix that follows.



   Prefix:

     A variable length field containing an address prefix whose length,
     in bits, was specified in the previous (Pre Len) field. A Prefix is
     padded with sufficient trailing zero bits  to cause the end of the
     field to fall on an octet boundary.


4.7. TDP_PIE_REQUEST_BIND

   TDP_PIE_REQUEST_BIND is sent from a TSR to a peer to request a bind-
   ing for one or more specific NLRIs, or to request all the bindings
   that its peer has.

   A TSR receiving a TDP_PIE_REQUEST_BIND must respond with a
   TDP_PIE_BIND or with a TDP_PIE_NOTIFICATION. A TSR that issues a
   TDP_PIE_BIND in response to a TDP_PIE_REQUEST_BIND places the Request



Doolan, et al.                                                 [Page 24]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


   ID from TDP_PIE_REQUEST_BIND in the Request ID field in the
   TDP_PIE_BIND that it issues.

   When a TSR receiving a TDP_PIE_REQUEST_BIND is unable to satisfy it
   because of resource limitations it issues a TDP_PIE_NOTIFICATION for
   RESOURCE_LIMIT containing the Request ID from the
   TDP_PIE_REQUEST_BIND.

   A TSR that issues  TDP_PIE_NOTIFICATION with RESOURCE_LIMIT set must
   send a subsequent TDP_PIE_NOTIFICATION, containing the status notifi-
   cation RESOURCES, to the peer to whom it previously sent that
   TDP_PIE_NOTIFICATION when it has resources available to satisfy
   further TDP_PIE_BIND_REQUESTs from that peer.

   If a TDP_PIE_NOTIFICATION is received containing RESOURCE_LIMIT the
   TSR may not issue further TDP_PIE_REQUEST_BINDs until it receives a
   TDP_PIE_NOTIFICATION with the Optional parameter RESOURCES.

   A TSR may receive a TDP_PIE_REQUEST_BIND for a prefix for which there
   is no entry in its router information base (RIB). If this occurs the
   TSR issues a TDP_PIE_NOTIFICATION containing the Optional parameter
   NO_ROUTE. The value field of the NO_ROUTE parameter contains the
   prefix(es) for which no entry was found in the RIB.

   The procedures to be employed by a TSR that receives a
   TDP_PIE_NOTIFICATION with the optional parameter NO_ROUTE are outside
   the scope of this specification.

   A TSR may issue TDP_PIE_BIND and TDP_PIE_NOTIFICATION containing
   RESOURCE_LIMIT or NO_ROUTE in response to a single
   TDP_PIE_REQUEST_BIND.  A TSR must satisfy as much of a
   TDP_PIE_REQUEST_BIND as it can. A TSR may not ignore other prefixes
   in a TDP_PIE_REQUEST_BIND on encountering an error with one prefix.

   This PIE has the following format:
















Doolan, et al.                                                 [Page 25]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997



            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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     TYPE (0x300)              |      LENGTH                   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           Request ID                                          |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           AFAM                |      ALIST_TYPE               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           ALIST_LENGTH        |                               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
           |           ADDR_LIST                                           |
           |           Variable length list consisting of one or           |
           |           more ALIST entries                                  |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                               |
           |                       Optional Parameters                     |
           |                       (Variable  Length)                      |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   TYPE:

     Type field as described above. Set to 0x300 for
     TDP_PIE_REQUEST_BIND.



   LENGTH:

     Length in octets of the  value field of this PIE. LENGTH  is set to
     the length of the whole PIE in octets minus four.



   Request ID:

     This four octet unsigned integer contains a locally significant non
     zero value that a TSR uses to identify TDP_PIE_BINDs or
     TDP_PIE_NOTIFICATIONs that are generated in response to this
     request.









Doolan, et al.                                                 [Page 26]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997




   AFAM:

     This 16 bit integer contains a value from ADDRESS FAMILY NUMBERS
     in Assigned Numbers [Reynolds] that encodes the address family that
     the network layer address in the tag bindings in the BINDING_LIST
     is from. This version of TDP supports IPv4 and IPv6.



   ALIST_TYPE:

     This 16 bit integer contains a value from the table below that
     encodes the format of the ALIST entries in the ADDR_LIST field.
     Currently there are  3 values defined by this specification.

             ALIST_TYPE      ALIST entry format
               0             Null list
               1             Precedence followed by variable length NLRI
               2             Precedence, Hop Count followed by variable length NLRI

     The format for these entries is defined below.



   ALIST_LENGTH:

     Two octet unsigned integer that encodes the length in octets of the
     ADDR_LIST field.



   ADDR_LIST:

     A variable length list consisting of one or more entries of type
     ALIST_TYPE.



   Optional Parameters:

     This variable length field contains zero or more optional PIEs sup-
     plied in TLV structures.







Doolan, et al.                                                 [Page 27]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


4.7.1. ALIST formats

   ALIST_TYPE = 0 indicates a  null list ie there are no ALIST entries.
   A TDP receiving a TDP_PIE_REQUEST_BIND with ALIST_TYPE set to 0
   interprets this as an implicit request for all the bindings that it
   currently has.

   For ALIST_TYPE = 1 ALIST entries have  the following form:


            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
           +-+-+-+-+-+-+-+-+
           |   Precedence  |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |    Pre Len    |   Prefix  (length variable ....................
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            .....................
           +-+-+-+-+-+-+-+-+-+-+-


   For ALIST_TYPE = 2 ALIST entries have  the following form:


            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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |   Precedence  |      HC       |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |    Pre Len    |   Prefix  (length variable ....................
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            .....................
           +-+-+-+-+-+-+-+-+-+-+-





   HC:

     Hop count.



   Precedence:

     This one octet unsigned integer encodes the precedence with which
     the requestor wants traffic to this prefix handled.



Doolan, et al.                                                 [Page 28]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997




   Pre Len:

     This one octet unsigned integer contains the length in bits of the
     address prefix that follows.



   Prefix:

     A variable length field containing an address prefix whose length,
     in bits, was specified in the previous (Pre Len) field. A Prefix is
     padded with sufficient trailing zero bits  to cause the end of the
     field to fall on an octet boundary.


4.7.2. Errors

   Errors are reported using TDP_PIE_NOTIFICATION.


           +-----------------------+----------+--------+--------------+
           | STATUS NOTIFICATION   | Type     | Length | Value        |
           +-----------------------+----------+--------+--------------+
           | RESOURCE_LIMIT        | 0x3F0    |   4    | Request ID   |
           +-----------------------+----------+--------+--------------+
           | RESOURCES             | 0x3F1    |   0    | 0            |
           +-----------------------+----------+--------+--------------+
           | HOP_COUNT_EQUALLED    | 0x3F2    |   Var  | See below    |
           +-----------------------+----------+--------+--------------+
           | NO_ROUTE              | 0x3F3    |   Var  | See below    |
           +-----------------------+----------+--------+--------------+



   RESOURCE_LIMIT:

   If the TSR is unable to provide a TDP_PIE_BIND in response to a
   request the TSR indicates this by supplying the RESOURCE_LIMIT status
   notification as a parameter in the TDP_PIE_NOTIFICATION. The Request
   ID from the the TPD_PIE_REQUEST bind is supplied in the Value field
   of this status notification

   RESOURCES:

   A TSR that has sent  RESOURCE_LIMIT to a peer sends RESOURCES when
   that resource limit clears.



Doolan, et al.                                                 [Page 29]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


   HOP_COUNT_EQUALLED:

   An ATM_TSR that receives a TDP_PIE_BIND_REQUEST containing a
   HOP_COUNT that equals MAX_HOP_COUNT does not generate a binding but
   instead sends this error notification. The length is variable and the
   value returns the Request ID and the ALIST entry(ies) that caused the
   error in 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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |       Request ID                                              |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |       HC      | Precedence    | Pre Len       | Prefix ......
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            (length variable) ....................
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
           |       HC      | Precedence    | Pre Len       | Prefix ......
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            (length variable) ....................
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   NO_ROUTE:

   A TSR that has no RIB entry for a prefix that it receives in a
   TDP_PIE_REQUEST_BIND issues a notification containing this parameter
   for that prefix(es). The value field of this parameter contains the
   Request_ID, AFAM, ALIST_TYPE from the TDP_PIE_REQUEST_BIND and a
   suitably modified ALIST_LENGTH and ADDR_LIST in the following format.

   See section 4.7 for descriptions of the Request_ID,AFAM, ALIST_TYPE,
   ALIST_LENGTH and ADDR_LIST elements.















Doolan, et al.                                                 [Page 30]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997



           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           Request ID                                          |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           AFAM                |      ALIST_TYPE               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           ALIST_LENGTH        | Variable length list of       |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ prefixes for which no RIB     |
           | entry exists in ADDR_LIST format..............................
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           +-+-+-+-+








































Doolan, et al.                                                 [Page 31]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


4.8. TDP_PIE_WITHDRAW_BIND

   TDP_PIE_WITHDRAW_BIND is issued by a TSR that originally provided a
   binding containing the tag in question and is an absolute instruction
   to the TSR that receives it that it may not continue to use that tag
   to forward traffic to the TSR issuing the TDP_PIE_WITHDRAW_BIND.

   This PIE has 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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     TYPE (0x400)              |      LENGTH                   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           BLIST_TYPE          |      BLIST_LENGTH             |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           BINDING_LIST                                        |
           |           Variable length list consisting of one or           |
           |           more BLIST entries ....                             |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                               |
           |                       Optional Parameters                     |
           |                       (Variable  Length)                      |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





   TYPE:

     Type field as described above. Set to 0x400 for
     TDP_PIE_WITHDRAW_BIND.



   LENGTH:

     Length in octets of the  value field of this PIE. LENGTH  is set to
     the length of the whole PIE in octets minus four.



   BLIST_TYPE

     This 16 bit integer encodes the format of the BLIST entries in the
     BINDING_LIST field. Possible values are defined in Section 4.6.  A
     TDP receiving this PIE with the BLIST_TYPE set to Null interprets



Doolan, et al.                                                 [Page 32]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


     it (based on the semantics) as either (a) an implicit instruction
     to WITHDRAW all bindings belonging to the peer that issued the PIE,
     or (b) as an indication that all the bindings requested by the peer
     are no longer needed by the peer that issued the PIE.



   BLIST_LENGTH:

     This 16 bit unsigned integer encodes the length in octets of the
     BINDING_LIST.



   BINDING_LIST:

     Variable length field consisting of one or more BLIST entries of
     the type indicated by BLIST_TYPE. The format of these entries is
     defined in Section 4.6.



   Optional Parameters:

     This variable length field contains zero or more optional PIEs sup-
     plied in TLV structures.

























Doolan, et al.                                                 [Page 33]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


4.9. TDP_PIE_RELEASE_BIND

   TDP_PIE_RELEASE_BIND is issued by a TSR that received a tag as a
   consequence of an Upstream Request/downstream assignment sequence.
   It is an indication to the TSR that receives it that the TSR that
   requested the binding no longer needs that binding.

   This PIE has, with the exception of a different type value exactly
   the same syntax as TDP_PIE_WITHDRAW_BIND.

            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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     TYPE (0x700)              |      LENGTH                   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           BLIST_TYPE          |      BLIST_LENGTH             |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |           BINDING_LIST                                        |
           |           Variable length list consisting of one or           |
           |           more BLIST entries ....                             |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                               |
           |                       Optional Parameters                     |
           |                       (Variable  Length)                      |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   See the discussion of TDP_PIE_WITHDRAW_BIND for details of the syn-
   tax.



   Optional Parameters:

     This variable length field contains zero or more optional PIEs sup-
     plied in TLV structures.















Doolan, et al.                                                 [Page 34]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


4.10. TDP_PIE_KEEP_ALIVE

   The Hold Timer mechanism described earlier in Sections 3 and 4 is
   reset every time a TDP_PDU is received. TDP_PIE_KEEP_ALIVE is pro-
   vided to allow reset of the Hold Timer in circumstances where a TDP
   has no other information to communicate to its peer.

   A TDP must arrange that its peer sees a TDP_PDU from it at least
   every HOLD_TIME period. That PDU may be any other from the protocol
   or, in circumstances where there is no need to send one of them, it
   must be TDP_PIE_KEEP_ALIVE.

   This PIE has 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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     TYPE (0x500)              |      LENGTH                   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                               |
           |                       Optional Parameters                     |
           |                       (Variable  Length)                      |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




   TYPE:

     Type field as described above. Set to 0x500 for TDP_PIE_KEEP_ALIVE.



   LENGTH:

     Length in octets of the  value field of this PIE. LENGTH  is set to
     the length of the whole PIE in octets minus four.



   Optional Parameters:

     This variable length field contains zero or more optional PIEs sup-
     plied in TLV structures.







Doolan, et al.                                                 [Page 35]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


4.11. TDP_PIE_NOTIFICATION

   TDP_PIE_NOTIFICATION is issued by TDP to inform its peer of a signi-
   ficant event. 'Significant events' include errors  and changes in TSR
   capabilities or operational state.

   All notification information is encoded as TLVs in the optional
   parameters field.

   This PIE has 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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     TYPE (0x600)              |      LENGTH                   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                                                               |
           |                       Optional Parameters                     |
           |                       (Variable  Length)                      |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




   TYPE:

     Type field as described above. Set to 0x600 for
     TDP_PIE_NOTIFICATION



   LENGTH:

     Length in octets of the  value field of this PIE. LENGTH  is set to
     the length of the whole PIE in octets minus four.



   Optional Parameters:

     This variable length field contains zero or more optional parame-
     ters supplied in TLV structures.

     The optional parameter types and their uses are:







Doolan, et al.                                                 [Page 36]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


          RETURNED_PDU:

          A TSR uses this parameter to return a PDU to the TSR that
          issued it.

                  +--------------------------+-------+--------+--------------+
                  | Optional Parameter       | Type  | Length | Value        |
                  +--------------------------+-------+--------+--------------+
                  | RETURNED_PDU             | 0x601 |  Var   | Peer's PDU   |
                  +--------------------------+-------+--------+--------------+

          As much as possible of the complete PDU, including the header,
          that is to be returned is inserted into the value field. The
          Length is set to the the number of octets of the PDU that is
          being returned that have been inserted into the Value field of
          this optional parameter. Implementations parsing RETURNED_PDU
          must be careful to recognize that the returned PDU may have
          been truncated.

































Doolan, et al.                                                 [Page 37]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


          CLOSING: A TSR uses this parameter to indicate that it is ter-
          minating the TDP session.

                  +--------------------------+-------+--------+--------------+
                  | Optional Parameter       | Type  | Length | Value        |
                  +--------------------------+-------+--------+--------------+
                  | CLOSING                  | 0x602 |   0    |     0        |
                  +--------------------------+-------+--------+--------------+

          TDP may send a TDP_PIE_NOTIFICATION with CLOSING set in
          response to a protocol error or to administrative interven-
          tion.

          A TDP receiving or issuing this notification transitions to
          the INITIALIZED state.


          The following optional parameters are defined for returning
          errors from individual PIEs. See the description of the
          relevant PIEs for a complete description of the errors.

          TDP_PIE_OPEN:

                  +--------------------------+----------+
                  | Optional Parameter       | Type     |
                  +--------------------------+----------+
                  | TDP_OPEN_UNSUPPORTED_VER | 0x1F0    |
                  +--------------------------+----------+
                  | TDP_BAD_OPEN             | 0x1F1    |
                  +--------------------------+----------+
                  | TDP_WRONG_ENCAPS         | 0x1F2    |
                  +--------------------------+----------+


          TDP_PIE_REQUEST_BIND:

                  +--------------------------+----------+
                  | Optional Parameter       | Type     |
                  +--------------------------+----------+
                  | RESOURCE_LIMIT           | 0x3F0    |
                  +--------------------------+----------+
                  | RESOURCES                | 0x3F1    |
                  +--------------------------+----------+
                  | HOP_COUNT_EQUALLED       | 0x3F2    |
                  +--------------------------+----------+
                  | NO_ROUTE                 | 0x3F3    |
                  +--------------------------+----------+




Doolan, et al.                                                 [Page 38]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


5. Intellectual Property Considerations

   Cisco Systems may seek patent or other intellectual property protec-
   tion for some or all of the technologies disclosed in this document.
   If any standards arising from this document are or become protected
   by one or more patents assigned to Cisco Systems, Cisco intends to
   disclose those patents and license them on reasonable and non-
   discriminatory terms.


6. Acknowledgments

   Jim Gibson, Keith McCloghrie, Alex Raj, Dan Tappan and Bob Thomas
   pointed out omissions and errors in the previous version of this
   document and provided guidance on the definition of new capabilities.


7. References

   [Deering] Deering, S. et al "An Architecture for Wide Area Multicast
   Routing", Pro Sigcomm 94 in Computer Communications Review Vol 24 No
   4.

   [Davie] Davie, B. et al "draft-davie-tag-switching-atm-01.txt"

   [Heinanen] Heinanen, J. "Multiprotocol Encapsulation over ATM Adapta-
   tion Layer 5" RFC1483, July 1993

   [Rekhter] Rekhter, Y. et al "draft-rfced-tag-switching-overview-
   00.txt".

   [Reynolds] Reynolds J, Postel J. "Assigned numbers"  RFC 1700,
   October 1994


















Doolan, et al.                                                 [Page 39]


Internet Draft        draft-doolan-tdp-spec-01.txt              May 1997


8. Author Information

   Paul Doolan
   cisco Systems, Inc.
   250 Apollo Drive.
   Chelmsford, MA 01824
   Phone: (508) 244-8917
   email: pdoolan@cisco.com

   Bruce Davie
   cisco Systems, Inc.
   250 Apollo Dr.
   Chelmsford, MA 01824
   email: bsd@cisco.com

   Dave Katz
   Juniper Networks, Inc.
   3260 Jay St.
   Santa Clara, CA, 95054
   email: dkatz@jnx.com

   Yakov Rekhter
   cisco Systems, Inc.
   170 Tasman Dr.
   San Jose, CA 95134
   email: yakov@cisco.com

   Eric Rosen
   cisco Systems, Inc.
   250 Apollo Dr.
   Chelmsford, MA 01824
   email: erosen@cisco.com



















Doolan, et al.                                                 [Page 40]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/