tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3931

 
 
 

Layer Two Tunneling Protocol - Version 3 (L2TPv3)

Part 3 of 5, p. 36 to 59
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 36 
5.4.  AVP Summary

   The following sections contain a list of all L2TP AVPs defined in
   this document.

   Following the name of the AVP is a list indicating the message types
   that utilize each AVP.  After each AVP title follows a short
   description of the purpose of the AVP, a detail (including a graphic)
   of the format for the Attribute Value, and any additional information
   needed for proper use of the AVP.

5.4.1.  General Control Message AVPs

   Message Type (All Messages)

      The Message Type AVP, Attribute Type 0, identifies the control
      message herein and defines the context in which the exact meaning
      of the following AVPs will be determined.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Message Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type is a 2-octet unsigned integer.

      The Message Type AVP MUST be the first AVP in a message,
      immediately following the control message header (defined in
      Section 3.2.1).  See Section 3.1 for the list of defined control
      message types and their identifiers.

Top      Up      ToC       Page 37 
      The Mandatory (M) bit within the Message Type AVP has special
      meaning.  Rather than an indication as to whether the AVP itself
      should be ignored if not recognized, it is an indication as to
      whether the control message itself should be ignored.  If the M
      bit is set within the Message Type AVP and the Message Type is
      unknown to the implementation, the control connection MUST be
      cleared.  If the M bit is not set, then the implementation may
      ignore an unknown message type.  The M bit MUST be set to 1 for
      all message types defined in this document.  This AVP MUST NOT be
      hidden (the H bit MUST be 0).  The Length of this AVP is 8.

      A vendor-specific control message may be defined by setting the
      Vendor ID of the Message Type AVP to a value other than the IETF
      Vendor ID of 0 (see Section 5.1).  The Message Type AVP MUST still
      be the first AVP in the control message.

   Message Digest (All Messages)

      The Message Digest AVP, Attribute Type 59 is used as an integrity
      and authentication check of the L2TP Control Message header and
      body.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Digest Type  | Message Digest ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                        ... (16 or 20 octets)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Digest Type is a one-octet integer indicating the Digest
      calculation algorithm:

         0 HMAC-MD5 [RFC2104]
         1 HMAC-SHA-1 [RFC2104]

      Digest Type 0 (HMAC-MD5) MUST be supported, while Digest Type 1
      (HMAC-SHA-1) SHOULD be supported.

      The Message Digest is of variable length and contains the result
      of the control message authentication and integrity calculation.
      For Digest Type 0 (HMAC-MD5), the length of the digest MUST be 16

Top      Up      ToC       Page 38 
      bytes.  For Digest Type 1 (HMAC-SHA-1) the length of the digest
      MUST be 20 bytes.

      If Control Message Authentication is enabled, at least one Message
      Digest AVP MUST be present in all messages and MUST be placed
      immediately after the Message Type AVP.  This forces the Message
      Digest AVP to begin at a well-known and fixed offset.  A second
      Message Digest AVP MAY be present in a message and MUST be placed
      directly after the first Message Digest AVP.

      The shared secret between LCCEs is used to derive a unique shared
      key for Control Message Authentication calculations.  The derived
      shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with
      the key consisting of the shared secret, and with the data being
      hashed consisting of a single octet containing the value 2.

         shared_key = HMAC_MD5 (shared_secret, 2)

      Calculation of the Message Digest is as follows for all messages
      other than the SCCRQ (where "+" refers to concatenation):

         Message Digest = HMAC_Hash (shared_key, local_nonce +
                                     remote_nonce + control_message)

         HMAC_Hash: HMAC Hashing algorithm identified by the Digest Type
         (MD5 or SHA1)

         local_nonce: Nonce chosen locally and advertised to the remote
         LCCE.

         remote_nonce: Nonce received from the remote LCCE

         (The local_nonce and remote_nonce are advertised via the
         Control Message Authentication Nonce AVP, also defined in this
         section.)

         shared_key: Derived shared key for this control connection

         control_message: The entire contents of the L2TP control
         message, including the control message header and all AVPs.
         Note that the control message header in this case begins after
         the all-zero Session ID when running over IP (see Section
         4.1.1.2), and after the UDP header when running over UDP (see
         Section 4.1.2.1).

      When calculating the Message Digest, the Message Digest AVP MUST
      be present within the control message with the Digest Type set to
      its proper value, but the Message Digest itself set to zeros.

Top      Up      ToC       Page 39 
      When receiving a control message, the contents of the Message
      Digest AVP MUST be compared against the expected digest value
      based on local calculation.  This is done by performing the same
      digest calculation above, with the local_nonce and remote_nonce
      reversed.  This message authenticity and integrity checking MUST
      be performed before utilizing any information contained within the
      control message.  If the calculation fails, the message MUST be
      dropped.

      The SCCRQ has special treatment as it is the initial message
      commencing a new control connection.  As such, there is only one
      nonce available.  Since the nonce is present within the message
      itself as part of the Control Message Authentication Nonce AVP,
      there is no need to use it in the calculation explicitly.
      Calculation of the SCCRQ Message Digest is performed as follows:

         Message Digest = HMAC_Hash (shared_key, control_message)

      To allow for graceful switchover to a new shared secret or hash
      algorithm, two Message Digest AVPs MAY be present in a control
      message, and two shared secrets MAY be configured for a given
      LCCE.  If two Message Digest AVPs are received in a control
      message, the message MUST be accepted if either Message Digest is
      valid.  If two shared secrets are configured, each (separately)
      MUST be used for calculating a digest to be compared to the
      Message Digest(s) received.  When calculating a digest for a
      control message, the Value field for both of the Message Digest
      AVPs MUST be set to zero.

      This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type
      2 (HMAC-SHA-1).

   Control Message Authentication Nonce (SCCRQ, SCCRP)

      The Control Message Authentication Nonce AVP, Attribute Type 73,
      MUST contain a cryptographically random value [RFC1750].  This
      value is used for Control Message Authentication.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Nonce ... (arbitrary number of octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 40 
      The Nonce is of arbitrary length, though at least 16 octets is
      recommended.  The Nonce contains the random value for use in the
      Control Message Authentication hash calculation (see Message
      Digest AVP definition in this section).

      If Control Message Authentication is enabled, this AVP MUST be
      present in the SCCRQ and SCCRP messages.

      This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length of this AVP is 6 plus the length of the Nonce.

   Random Vector (All Messages)

      The Random Vector AVP, Attribute Type 36, MUST contain a
      cryptographically random value [RFC1750].  This value is used for
      AVP Hiding.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Random Octet String ... (arbitrary number of octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Random Octet String is of arbitrary length, though at least 16
      octets is recommended.  The string contains the random vector for
      use in computing the MD5 hash to retrieve or hide the Attribute
      Value of a hidden AVP (see Section 5.3).

      More than one Random Vector AVP may appear in a message, in which
      case a hidden AVP uses the Random Vector AVP most closely
      preceding it.  As such, at least one Random Vector AVP MUST
      precede the first AVP with the H bit set.

      This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length of this AVP is 6 plus the length of the Random Octet
      String.

5.4.2.  Result and Error Codes

   Result Code (StopCCN, CDN)

      The Result Code AVP, Attribute Type 1, indicates the reason for
      terminating the control connection or session.

Top      Up      ToC       Page 41 
      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Result Code          |     Error Code (optional)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Error Message ... (optional, arbitrary number of octets)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Result Code is a 2-octet unsigned integer.  The optional Error
      Code is a 2-octet unsigned integer.  An optional Error Message can
      follow the Error Code field.  Presence of the Error Code and
      Message is indicated by the AVP Length field.  The Error Message
      contains an arbitrary string providing further (human-readable)
      text associated with the condition.  Human-readable text in all
      error messages MUST be provided in the UTF-8 charset [RFC3629]
      using the Default Language [RFC2277].

      This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length is 8 if there is no Error Code or Message, 10 if there is
      an Error Code and no Error Message, or 10 plus the length of the
      Error Message if there is an Error Code and Message.

      Defined Result Code values for the StopCCN message are as follows:

         0 - Reserved.
         1 - General request to clear control connection.
         2 - General error, Error Code indicates the problem.
         3 - Control connection already exists.
         4 - Requester is not authorized to establish a control
             connection.
         5 - The protocol version of the requester is not supported,
             Error Code indicates highest version supported.
         6 - Requester is being shut down.
         7 - Finite state machine error or timeout

      General Result Code values for the CDN message are as follows:

         0 - Reserved.
         1 - Session disconnected due to loss of carrier or
             circuit disconnect.
         2 - Session disconnected for the reason indicated in Error
             Code.
         3 - Session disconnected for administrative reasons.
         4 - Session establishment failed due to lack of appropriate
             facilities being available (temporary condition).

Top      Up      ToC       Page 42 
         5 - Session establishment failed due to lack of appropriate
             facilities being available (permanent condition).
        13 - Session not established due to losing tie breaker.
        14 - Session not established due to unsupported PW type.
        15 - Session not established, sequencing required without
             valid L2-Specific Sublayer.
        16 - Finite state machine error or timeout.

      Additional service-specific Result Codes are defined outside this
      document.

      The Error Codes defined below pertain to types of errors that are
      not specific to any particular L2TP request, but rather to
      protocol or message format errors.  If an L2TP reply indicates in
      its Result Code that a General Error occurred, the General Error
      value should be examined to determine what the error was.  The
      currently defined General Error codes and their meanings are as
      follows:

      0 - No General Error.
      1 - No control connection exists yet for this pair of LCCEs.
      2 - Length is wrong.
      3 - One of the field values was out of range.
      4 - Insufficient resources to handle this operation now.
      5 - Invalid Session ID.
      6 - A generic vendor-specific error occurred.
      7 - Try another.  If initiator is aware of other possible
          responder destinations, it should try one of them.  This can
          be used to guide an LAC or LNS based on policy.
      8 - The session or control connection was shut down due to receipt
          of an unknown AVP with the M bit set (see Section 5.2).  The
          Error Message SHOULD contain the attribute of the offending
          AVP in (human-readable) text form.
      9 - Try another directed.  If an LAC or LNS is aware of other
          possible destinations, it should inform the initiator of the
          control connection or session.  The Error Message MUST contain
          a comma-separated list of addresses from which the initiator
          may choose.  If the L2TP data channel runs over IPv4, then
          this would be a comma-separated list of IP addresses in the
          canonical dotted-decimal format (e.g., "192.0.2.1, 192.0.2.2,
          192.0.2.3") in the UTF-8 charset [RFC3629] using the Default
          Language [RFC2277].  If there are no servers for the LAC or
          LNS to suggest, then Error Code 7 should be used.  For IPv4,
          the delimiter between addresses MUST be precisely a single
          comma and a single space.  For IPv6, each literal address MUST
          be enclosed in "[" and "]" characters, following the encoding
          described in [RFC2732].

Top      Up      ToC       Page 43 
      When a General Error Code of 6 is used, additional information
      about the error SHOULD be included in the Error Message field.  A
      vendor-specific AVP MAY be sent to more precisely detail a
      vendor-specific problem.

5.4.3.  Control Connection Management AVPs

   Control Connection Tie Breaker (SCCRQ)

      The Control Connection Tie Breaker AVP, Attribute Type 5,
      indicates that the sender desires a single control connection to
      exist between a given pair of LCCEs.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Control Connection Tie Breaker Value ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                 ... (64 bits)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Control Connection Tie Breaker Value is an 8-octet random
      value that is used to choose a single control connection when two
      LCCEs request a control connection concurrently.  The recipient of
      a SCCRQ must check to see if a SCCRQ has been sent to the peer; if
      so, a tie has been detected.  In this case, the LCCE must compare
      its Control Connection Tie Breaker value with the one received in
      the SCCRQ.  The lower value "wins", and the "loser" MUST discard
      its control connection.  A StopCCN SHOULD be sent by the winner as
      an explicit rejection for the losing SCCRQ.  In the case in which
      a tie breaker is present on both sides and the value is equal,
      both sides MUST discard their control connections and restart
      control connection negotiation with a new, random tie breaker
      value.

      If a tie breaker is received and an outstanding SCCRQ has no tie
      breaker value, the initiator that included the Control Connection
      Tie Breaker AVP "wins".  If neither side issues a tie breaker,
      then two separate control connections are opened.

      Applications that employ a distinct and well-known initiator have
      no need for tie breaking, and MAY omit this AVP or disable tie
      breaking functionality.  Applications that require tie breaking
      also require that an LCCE be uniquely identifiable upon receipt of
      an SCCRQ.  For L2TP over IP, this MUST be accomplished via the
      Router ID AVP.

Top      Up      ToC       Page 44 
      Note that in [RFC2661], this AVP is referred to as the "Tie
      Breaker AVP" and is applicable only to a control connection.  In
      L2TPv3, the AVP serves the same purpose of tie breaking, but is
      applicable to a control connection or a session.  The Control
      Connection Tie Breaker AVP (present only in Control Connection
      messages) and Session Tie Breaker AVP (present only in Session
      messages), are described separately in this document, but share
      the same Attribute type of 5.

      This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      length of this AVP is 14.

   Host Name (SCCRQ, SCCRP)

      The Host Name AVP, Attribute Type 7, indicates the name of the
      issuing LAC or LNS, encoded in the US-ASCII charset.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Host Name ... (arbitrary number of octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Host Name is of arbitrary length, but MUST be at least 1
      octet.

      This name should be as broadly unique as possible; for hosts
      participating in DNS [RFC1034], a host name with fully qualified
      domain would be appropriate.  The Host Name AVP and/or Router ID
      AVP MUST be used to identify an LCCE as described in Section 3.3.

      This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length of this AVP is 6 plus the length of the Host Name.

   Router ID (SCCRQ, SCCRP)

      The Router ID AVP, Attribute Type 60, is an identifier used to
      identify an LCCE for control connection setup, tie breaking,
      and/or tunnel authentication.

Top      Up      ToC       Page 45 
      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Router Identifier                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Router Identifier is a 4-octet unsigned integer.  Its value is
      unique for a given LCCE, per Section 8.1 of [RFC2072].  The Host
      Name AVP and/or Router ID AVP MUST be used to identify an LCCE as
      described in Section 3.3.

      Implementations MUST NOT assume that Router Identifier is a valid
      IP address.  The Router Identifier for L2TP over IPv6 can be
      obtained from an IPv4 address (if available) or via unspecified
      implementation-specific means.

      This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length of this AVP is 10.

   Vendor Name (SCCRQ, SCCRP)

      The Vendor Name AVP, Attribute Type 8, contains a vendor-specific
      (possibly human-readable) string describing the type of LAC or LNS
      being used.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Vendor Name ... (arbitrary number of octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Vendor Name is the indicated number of octets representing the
      vendor string.  Human-readable text for this AVP MUST be provided
      in the US-ASCII charset [RFC1958, RFC2277].

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 6 plus the length of the
      Vendor Name.

Top      Up      ToC       Page 46 
   Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN)

      The Assigned Control Connection ID AVP, Attribute Type 61,
      contains the ID being assigned to this control connection by the
      sender.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Assigned Control Connection ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Assigned Control Connection ID is a 4-octet non-zero unsigned
      integer.

      The Assigned Control Connection ID AVP establishes the identifier
      used to multiplex and demultiplex multiple control connections
      between a pair of LCCEs.  Once the Assigned Control Connection ID
      AVP has been received by an LCCE, the Control Connection ID
      specified in the AVP MUST be included in the Control Connection ID
      field of all control packets sent to the peer for the lifetime of
      the control connection.  Before the Assigned Control Connection ID
      AVP is received from a peer, all control messages MUST be sent to
      that peer with a Control Connection ID value of 0 in the header.
      Because a Control Connection ID value of 0 is used in this special
      manner, the zero value MUST NOT be sent as an Assigned Control
      Connection ID value.

      Under certain circumstances, an LCCE may need to send a StopCCN to
      a peer without having yet received an Assigned Control Connection
      ID AVP from the peer (i.e., SCCRQ sent, no SCCRP received yet).
      In this case, the Assigned Control Connection ID AVP that had been
      sent to the peer earlier (i.e., in the SCCRQ) MUST be sent as the
      Assigned Control Connection ID AVP in the StopCCN.  This policy
      allows the peer to try to identify the appropriate control
      connection via a reverse lookup.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 10.

   Receive Window Size (SCCRQ, SCCRP)

      The Receive Window Size AVP, Attribute Type 10, specifies the
      receive window size being offered to the remote peer.

Top      Up      ToC       Page 47 
      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Window Size           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Window Size is a 2-octet unsigned integer.

      If absent, the peer must assume a Window Size of 4 for its
      transmit window.

      The remote peer may send the specified number of control messages
      before it must wait for an acknowledgment.  See Section 4.2 for
      more information on reliable control message delivery.

      This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length of this AVP is 8.

   Pseudowire Capabilities List (SCCRQ, SCCRP)

      The Pseudowire Capabilities List (PW Capabilities List) AVP,
      Attribute Type 62, indicates the L2 payload types the sender can
      support.  The specific payload type of a given session is
      identified by the Pseudowire Type AVP.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           PW Type 0           |             ...               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              ...              |          PW Type N            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Defined PW types that may appear in this list are managed by IANA
      and will appear in associated pseudowire-specific documents for
      each PW type.

      If a sender includes a given PW type in the PW Capabilities List
      AVP, the sender assumes full responsibility for supporting that
      particular payload, such as any payload-specific AVPs, L2-Specific
      Sublayer, or control messages that may be defined in the
      appropriate companion document.

Top      Up      ToC       Page 48 
      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 8 octets with one PW type
      specified, plus 2 octets for each additional PW type.

   Preferred Language (SCCRQ, SCCRP)

      The Preferred Language AVP, Attribute Type 72, provides a method
      for an LCCE to indicate to the peer the language in which human-
      readable messages it sends SHOULD be composed.  This AVP contains
      a single language tag or language range [RFC3066].

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Preferred Language... (arbitrary number of octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Preferred Language is the indicated number of octets
      representing the language tag or language range, encoded in the
      US-ASCII charset.

      It is not required to send a Preferred Language AVP.  If (1) an
      LCCE does not signify a language preference by the inclusion of
      this AVP in the SCCRQ or SCCRP, (2) the Preferred Language AVP is
      unrecognized, or (3) the requested language is not supported by
      the peer LCCE, the default language [RFC2277] MUST be used for all
      internationalized strings sent by the peer.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 6 plus the length of the
      Preferred Language.

5.4.4.  Session Management AVPs

   Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)

      The Local Session ID AVP (analogous to the Assigned Session ID in
      L2TPv2), Attribute Type 63, contains the identifier being assigned
      to this session by the sender.

Top      Up      ToC       Page 49 
      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Local Session ID                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Local Session ID is a 4-octet non-zero unsigned integer.

      The Local Session ID AVP establishes the two identifiers used to
      multiplex and demultiplex sessions between two LCCEs.  Each LCCE
      chooses any free value it desires, and sends it to the remote LCCE
      using this AVP.  The remote LCCE MUST then send all data packets
      associated with this session using this value.  Additionally, for
      all session-oriented control messages sent after this AVP is
      received (e.g., ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST
      echo this value in the Remote Session ID AVP.

      Note that a Session ID value is unidirectional.  Because each LCCE
      chooses its Session ID independent of its peer LCCE, the value
      does not have to match in each direction for a given session.

      See Section 4.1 for additional information about the Session ID.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2).
      The Length (before hiding) of this AVP is 10.

   Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)

      The Remote Session ID AVP, Attribute Type 64, contains the
      identifier that was assigned to this session by the peer.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Remote Session ID                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Remote Session ID is a 4-octet non-zero unsigned integer.

      The Remote Session ID AVP MUST be present in all session-level
      control messages.  The AVP's value echoes the session identifier
      advertised by the peer via the Local Session ID AVP.  It is the
      same value that will be used in all transmitted data messages by

Top      Up      ToC       Page 50 
      this side of the session.  In most cases, this identifier is
      sufficient for the peer to look up session-level context for this
      control message.

      When a session-level control message must be sent to the peer
      before the Local Session ID AVP has been received, the value of
      the Remote Session ID AVP MUST be set to zero.  Additionally, the
      Local Session ID AVP (sent in a previous control message for this
      session) MUST be included in the control message.  The peer must
      then use the Local Session ID AVP to perform a reverse lookup to
      find its session context.  Session-level control messages defined
      in this document that might be subject to a reverse lookup by a
      receiving peer include the CDN, WEN, and SLI.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 10.

   Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP)

      The Assigned Cookie AVP, Attribute Type 65, contains the Cookie
      value being assigned to this session by the sender.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Assigned Cookie (32 or 64 bits) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Assigned Cookie is a 4-octet or 8-octet random value.

      The Assigned Cookie AVP contains the value used to check the
      association of a received data message with the session identified
      by the Session ID.  All data messages sent to a peer MUST use the
      Assigned Cookie sent by the peer in this AVP.  The value's length
      (0, 32, or 64 bits) is obtained by the length of the AVP.

      A missing Assigned Cookie AVP or Assigned Cookie Value of zero
      length indicates that the Cookie field should not be present in
      any data packets sent to the LCCE sending this AVP.

      See Section 4.1 for additional information about the Assigned
      Cookie.

Top      Up      ToC       Page 51 
      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP may be 6, 10, or 14 octets.

   Serial Number (ICRQ, OCRQ)

      The Serial Number AVP, Attribute Type 15, contains an identifier
      assigned by the LAC or LNS to this session.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Serial Number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Serial Number is a 32-bit value.

      The Serial Number is intended to be an easy reference for
      administrators on both ends of a control connection to use when
      investigating session failure problems.  Serial Numbers should be
      set to progressively increasing values, which are likely to be
      unique for a significant period of time across all interconnected
      LNSs and LACs.

      Note that in RFC 2661, this value was referred to as the "Call
      Serial Number AVP".  It serves the same purpose and has the same
      attribute value and composition.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 10.

   Remote End ID (ICRQ, OCRQ)

      The Remote End ID AVP, Attribute Type 66, contains an identifier
      used to bind L2TP sessions to a given circuit, interface, or
      bridging instance.  It also may be used to detect session-level
      ties.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Remote End Identifier ... (arbitrary number of octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 52 
      The Remote End Identifier field is a variable-length field whose
      value is unique for a given LCCE peer, as described in Section
      3.3.

      A session-level tie is detected if an LCCE receives an ICRQ or
      OCRQ with an End ID AVP whose value matches that which was just
      sent in an outgoing ICRQ or OCRQ to the same peer.  If the two
      values match, an LCCE recognizes that a tie exists (i.e., both
      LCCEs are attempting to establish sessions for the same circuit).
      The tie is broken by the Session Tie Breaker AVP.

      By default, the LAC-LAC cross-connect application (see Section
      2(b)) of L2TP over an IP network MUST utilize the Router ID AVP
      and Remote End ID AVP to associate a circuit to an L2TP session.
      Other AVPs MAY be used for LCCE or circuit identification as
      specified in companion documents.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 6 plus the length of the
      Remote End Identifier value.

   Session Tie Breaker (ICRQ, OCRQ)

      The Session Tie Breaker AVP, Attribute Type 5, is used to break
      ties when two peers concurrently attempt to establish a session
      for the same circuit.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Session Tie Breaker Value ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                 ... (64 bits)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Session Tie Breaker Value is an 8-octet random value that is
      used to choose a session when two LCCEs concurrently request a
      session for the same circuit.  A tie is detected by examining the
      peer's identity (described in Section 3.3) plus the per-session
      shared value communicated via the End ID AVP.  In the case of a
      tie, the recipient of an ICRQ or OCRQ must compare the received
      tie breaker value with the one that it sent earlier.  The LCCE
      with the lower value "wins" and MUST send a CDN with result code
      set to 13 (as defined in Section 5.4.2) in response to the losing
      ICRQ or OCRQ.  In the case in which a tie is detected, tie

Top      Up      ToC       Page 53 
      breakers are sent by both sides, and the tie breaker values are
      equal, both sides MUST discard their sessions and restart session
      negotiation with new random tie breaker values.

      If a tie is detected but only one side sends a Session Tie Breaker
      AVP, the session initiator that included the Session Tie Breaker
      AVP "wins".  If neither side issues a tie breaker, then both sides
      MUST tear down the session.

      This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length of this AVP is 14.

   Pseudowire Type (ICRQ, OCRQ)

      The Pseudowire Type (PW Type) AVP, Attribute Type 68, indicates
      the L2 payload type of the packets that will be tunneled using
      this L2TP session.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           PW Type             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      A peer MUST NOT request an incoming or outgoing call with a PW
      Type AVP specifying a value not advertised in the PW Capabilities
      List AVP it received during control connection establishment.
      Attempts to do so MUST result in the call being rejected via a CDN
      with the Result Code set to 14 (see Section 5.4.2).

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 8.

   L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)

      The L2-Specific Sublayer AVP, Attribute Type 69, indicates the
      presence and format of the L2-Specific Sublayer the sender of this
      AVP requires on all incoming data packets for this L2TP session.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   L2-Specific Sublayer Type   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 54 
      The L2-Specific Sublayer Type is a 2-octet unsigned integer with
      the following values defined in this document:

         0 - There is no L2-Specific Sublayer present.
         1 - The Default L2-Specific Sublayer (defined in Section 4.6)
             is used.

      If this AVP is received and has a value other than zero, the
      receiving LCCE MUST include the identified L2-Specific Sublayer in
      its outgoing data messages.  If the AVP is not received, it is
      assumed that there is no sublayer present.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 8.

   Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)

      The Data Sequencing AVP, Attribute Type 70, indicates that the
      sender requires some or all of the data packets that it receives
      to be sequenced.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Data Sequencing Level     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Data Sequencing Level is a 2-octet unsigned integer indicating
      the degree of incoming data traffic that the sender of this AVP
      wishes to be marked with sequence numbers.

      Defined Data Sequencing Levels are as follows:

         0 - No incoming data packets require sequencing.
         1 - Only non-IP data packets require sequencing.
         2 - All incoming data packets require sequencing.

      If a Data Sequencing Level of 0 is specified, there is no need to
      send packets with sequence numbers.  If sequence numbers are sent,
      they will be ignored upon receipt.  If no Data Sequencing AVP is
      received, a Data Sequencing Level of 0 is assumed.

      If a Data Sequencing Level of 1 is specified, only non-IP traffic
      carried within the tunneled L2 frame should have sequence numbers
      applied.  Non-IP traffic here refers to any packets that cannot be

Top      Up      ToC       Page 55 
      classified as an IP packet within their respective L2 framing
      (e.g., a PPP control packet or NETBIOS frame encapsulated by Frame
      Relay before being tunneled).  All traffic that can be classified
      as IP MUST be sent with no sequencing (i.e., the S bit in the L2-
      Specific Sublayer is set to zero).  If a packet is unable to be
      classified at all (e.g., because it has been compressed or
      encrypted at layer 2) or if an implementation is unable to perform
      such classification within L2 frames, all packets MUST be provided
      with sequence numbers (essentially falling back to a Data
      Sequencing Level of 2).

      If a Data Sequencing Level of 2 is specified, all traffic MUST be
      sequenced.

      Data sequencing may only be requested when there is an L2-Specific
      Sublayer present that can provide sequence numbers.  If sequencing
      is requested without requesting a L2-Specific Sublayer AVP, the
      session MUST be disconnected with a Result Code of 15 (see Section
      5.4.2).

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 8.

   Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)

      The Tx Connect Speed BPS AVP, Attribute Type 74, contains the
      speed of the facility chosen for the connection attempt.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Connect Speed in bps...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        ...Connect Speed in bps (64 bits)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Tx Connect Speed BPS is an 8-octet value indicating the speed
      in bits per second.  A value of zero indicates that the speed is
      indeterminable or that there is no physical point-to-point link.

      When the optional Rx Connect Speed AVP is present, the value in
      this AVP represents the transmit connect speed from the
      perspective of the LAC (i.e., data flowing from the LAC to the
      remote system).  When the optional Rx Connect Speed AVP is NOT
      present, the connection speed between the remote system and LAC is

Top      Up      ToC       Page 56 
      assumed to be symmetric and is represented by the single value in
      this AVP.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 14.

   Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)

      The Rx Connect Speed AVP, Attribute Type 75, represents the speed
      of the connection from the perspective of the LAC (i.e., data
      flowing from the remote system to the LAC).

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Connect Speed in bps...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        ...Connect Speed in bps (64 bits)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Connect Speed BPS is an 8-octet value indicating the speed in bits
      per second.  A value of zero indicates that the speed is
      indeterminable or that there is no physical point-to-point link.

      Presence of this AVP implies that the connection speed may be
      asymmetric with respect to the transmit connect speed given in the
      Tx Connect Speed AVP.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 14.

   Physical Channel ID (ICRQ, ICRP, OCRP)

      The Physical Channel ID AVP, Attribute Type 25, contains the
      vendor-specific physical channel number used for a call.

      The Attribute Value field for this AVP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 57 
      Physical Channel ID is a 4-octet value intended to be used for
      logging purposes only.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 10.

5.4.5.  Circuit Status AVPs

   Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI)

      The Circuit Status AVP, Attribute Type 71, indicates the initial
      status of or a status change in the circuit to which the session
      is bound.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved          |N|A|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The A (Active) bit indicates whether the circuit is
      up/active/ready (1) or down/inactive/not-ready (0).

      The N (New) bit indicates whether the circuit status indication is
      for a new circuit (1) or an existing circuit (0).  Links that have
      a similar mechanism available (e.g., Frame Relay) MUST map the
      setting of this bit to the associated signaling for that link.
      Otherwise, the New bit SHOULD still be set the first time the L2TP
      session is established after provisioning.

      The remaining bits are reserved for future use.  Reserved bits
      MUST be set to 0 when sending and ignored upon receipt.

      The Circuit Status AVP is used to advertise whether a circuit or
      interface bound to an L2TP session is up and ready to send and/or
      receive traffic.  Different circuit types have different names for
      status types.  For example, HDLC primary and secondary stations
      refer to a circuit as being "Receive Ready" or "Receive Not
      Ready", while Frame Relay refers to a circuit as "Active" or
      "Inactive".  This AVP adopts the latter terminology, though the
      concept remains the same regardless of the PW type for the L2TP
      session.

Top      Up      ToC       Page 58 
      In the simplest case, the circuit to which this AVP refers is a
      single physical interface, port, or circuit, depending on the
      application and the session setup.  The status indication in this
      AVP may then be used to provide simple ILMI interworking for a
      variety of circuit types.  For virtual or multipoint interfaces,
      the Circuit Status AVP is still utilized, but in this case, it
      refers to the state of an internal structure or a logical set of
      circuits.  Each PW-specific companion document MUST specify
      precisely how this AVP is translated for each circuit type.

      If this AVP is received with a Not Active notification for a given
      L2TP session, all data traffic for that session MUST cease (or not
      begin) in the direction of the sender of the Circuit Status AVP
      until the circuit is advertised as Active.

      The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP,
      OCRQ, and OCRP messages.  Often, the circuit type will be marked
      Active when initiated, but subsequently MAY be advertised as
      Inactive.  This indicates that an L2TP session is to be created,
      but that the interface or circuit is still not ready to pass
      traffic.  The ICCN, OCCN, and SLI control messages all MAY contain
      this AVP to update the status of the circuit after establishment
      of the L2TP session is requested.

      If additional circuit status information is needed for a given PW
      type, any new PW-specific AVPs MUST be defined in a separate
      document.  This AVP is only for general circuit status information
      generally applicable to all circuit/interface types.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 1, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 8.

   Circuit Errors (WEN)

      The Circuit Errors AVP, Attribute Type 34, conveys circuit error
      information to the peer.

Top      Up      ToC       Page 59 
      The Attribute Value field for this AVP 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
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
                                     |             Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Hardware Overruns                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Buffer Overruns                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Timeout Errors                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Alignment Errors                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The following fields are defined:

      Reserved: 2 octets of Reserved data is present (providing longword
         alignment within the AVP of the following values).  Reserved
         data MUST be zero on sending and ignored upon receipt.
      Hardware Overruns: Number of receive buffer overruns since call
         was established.
      Buffer Overruns: Number of buffer overruns detected since call was
         established.
      Timeout Errors: Number of timeouts since call was established.
      Alignment Errors: Number of alignment errors since call was
         established.

      This AVP MAY be hidden (the H bit MAY be 0 or 1).  The M bit for
      this AVP SHOULD be set to 0, but MAY vary (see Section 5.2).  The
      Length (before hiding) of this AVP is 32.



(page 59 continued on part 4)

Next RFC Part