RFC 3931
Layer Two Tunneling Protocol - Version 3 (L2TPv3)
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.
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
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.
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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).
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].
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.
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.
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.
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.
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.
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.
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
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.
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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)
