Subject: Change detail for l2tpbis

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 20 Jul 2000 14:47:24 -0400 (EDT)

Here is a summary of the most significant changes to RFC 2661 that 
was recently posted as draft-ietf-l2tpext-l2tpbis-00.txt. Not every 
small editorial change is identified here. To get a full 
representation of all changes, I recommend using wdiff. 

http://www.iro.umontreal.ca/contrib/wdiff

Each numbered change contains a description, and an excerpt from the text. 
(actual text) means that the new text from l2tpbis is included 
(wdiff) means that the wdiff output is included
I included actual text in cases where I felt the changes were 
significant enough (and thus the wdiff output cluttered enough) to 
inhibit clear reading of the new text.

#1 Offset field calculation clarification, new recommended maximum 
suggestion (actual text).

Section 3.1

   The Offset Size field specifies the number of octets past the L2TP
   header at which the payload data is expected to start. If the offset
   field is present, the L2TP header ends after the last octet of the
   offset padding. The offset field itself is considered part of the
   l2tp header, not part of the offset padding. Thus, an offset field
   with a value of zero will add two octets to the header length.
   Actual data within the offset padding is undefined. A recommended
   maximum for the offset value is 7, which allows for 8 octet
   alignment.

#2 New Error code for directing LAC to another LNS (actual text). Yes,
I see the "an comma" typo. 

Section 4.4.2

      9 - Try another directed. If the LNS is aware of other possible
          destinations, it should inform the LAC. The Error Message
          MUST contain an comma separated list of addresses for the LAC
          to choose from. If the L2TP transport is IPv4, then this would
          be a comma separated list of IP addresses in the canonical
          dotted-decimal format. i.e. "10.0.0.1, 10.0.0.2, 10.0.0.3"
          If there are no servers for the LNS to suggest, then Error
          Code 7 should be used. The delimiter between addresses MUST be
          precisely a single comma and a single space.

#3 Suggestion for vendor specific AVP to further clarify a general vendor error. (wdiff)

      When a General Error Code of 6 is used, additional information
      about the error SHOULD be included in the Error Message field.
      {+Further, a vendor specific AVP MAY be sent to indicate the problem
      more precisely.+}

#4 New Framing Capabilites, Bearer Capabilities, Framing Type and Bearer Type text. Most 
significant her is a new 'V' bit for a virtual Bearer, as well as clarificaiton of what
the Bearer and Framing Capabilities refer to. Specifically, Bearer and Framing Capabilities
are now defined as pertaining ONLY to the physical interfaces avaiable for dialout. We
had fundamental problems in the field determining whether these AVPs referred to
the ability of an LAC to place a call, or the LNS to terminate a specific framing or 
bearer type. One AVP cannot be used to specify both. We can consider having two AVPs here,
one for dialout and one for dialin if deemed necessary (actual text). 

Section 4.4.3

   Framing Capabilities (SCCRP, SCCRQ)

      The Framing Capabilities AVP, Attribute Type 3, provides the peer
      with an indication of the types of framing that will be accepted
      or requested 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Reserved for future framing type definitions          |A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Attribute Value field is a 32-bit mask, with two bits defined.
      If bit A is set, asynchronous framing is supported. If bit S is
      set, synchronous framing is supported.

      The framing capabilitiies defined in this AVP refer only to the
      physical interfaces available for dialout usage on an LAC. An LNS
      MUST not send an OCRQ with a Framing Type AVP specifying a value
      not advertised in this AVP.  Presence of this message is not a
      guarantee that a given outgoing call will be placed by the sender
      if requested, just that the physical capability exists.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) is 10.

   Bearer Capabilities (SCCRP, SCCRQ)

      The Bearer Capabilities AVP, Attribute Type 4, provides the peer
      with an indication of the bearer device types supported by the
      hardware interfaces of the sender for outgoing calls.

      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 for future bearer type definitions         |V|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This is a 32-bit mask, with two bits defined. If bit A is set,
      analog access is supported. If bit D is set, digital access is
      supported.  Bit V is set, virtual acces is supported. Virtual
      access refers to access where there is no physical point to point
      link.

      The framing capabilitiies defined in this AVP refer only to the
      physical interfaces available for dialout usage on an LAC. An LNS
      MUST not send an OCRQ with a Bearer Type AVP specifying a value
      not advertised in this AVP.

      This AVP MUST be present if the sender can place outgoing calls
      when requested. Presence of this message is not a guarantee that a
      given outgoing call will be placed by the sender if requested,
      just that the physical capability exists.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) is 10.

   Bearer Type (ICRQ, OCRQ)

      The Bearer Type AVP, Attribute Type 18,  encodes the bearer type
      for the incoming or outgoing 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved for future Bearer Types              |V|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Bearer Type is a 32-bit bit mask indicating the bearer
      capability of the call (ICRQ) or required for the call (OCRQ). Bit
      A refers to an analog channel. Bit D refers to a digital channel.
      Bit V (virtual) refers to a channel for which there is no physical
      point to point link.

      Bits set in the Bearer Type AVP in an OCRQ message indicate which
      bearer type(s) an outgoing call may be placed on.  If more than
      one bit is set, the LAC may choose which bearer type to place the
      call on. If no bits are set, any type of available channel may be
      used.

      Bits in the Value field of this AVP MUST only be set by the LNS
      for an OCRQ if the same bit was set in the Bearer Capabilities AVP
      received from the LAC during control connection establishment.

      Bits set in the Bearer Type AVP in an ICRQ message indicate what
      bearer type an incoming call was received on at the LAC. If no
      bits are set in an ICRQ, then it is assumed that the bearer type
      was indeterminable.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 10.

   Framing Type (ICCN, OCCN, OCRQ)

      The Framing Type AVP, Attribute Type 19, encodes the framing type
      for the incoming or outgoing 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved for future Framing Types               |A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Framing Type is a 32-bit mask, which indicates the type of PPP
      framing requested for an OCRQ, or the type of PPP framing
      negotiated for an OCCN or ICCN.

      Bit A indicates asynchronous framing. Bit S indicates synchronous
      framing. For an OCRQ, both may be set, indicating that the LAC may
      decide the type of framing to be used.

      For an ICRQ, only one framing type bit may be set. The framing
      type SHOULD be used as an indication to PPP on the LNS as to what
      link options to use for LCP negotiation [RFC1662]. For example, if
      the A bit is not set in the Framing Type AVP in an ICRQ message
      and an ACCM LCP option is requested by the PPP client, then the
      LNS should try to respond with no bits set in the ACCM mask as the
      LAC will likely not perform async mapping on a non-async
      interface. Similarly, if the S bit is set, PPP may wish to reject
      address field compression and protocol field compression options.

      Bits in the Value field of this AVP MUST only be set by the LNS
      for an OCRQ if it was set in the Framing Capabilities AVP received
      from the LAC during control connection establishment.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 10.

#5 Clarification as to what 0 connect speed means. (wdiff)

   (Tx) Connect Speed (ICCN, OCCN)

      The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             BPS                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The (Tx) Connect Speed BPS is a 4 octet value indicating the speed
      in bits per second. {+A value of zero indicates that the speed is
      indeterminable, or there is no physical point to point link.+}

   Rx Connect Speed (ICCN, OCCN)

      The Rx Connect Speed AVP, Attribute Type 38, represents the speed
      of the connection from the perspective of the LAC (e.g. 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           BPS (H)             |            BPS (L)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      BPS is a 4 octet value indicating the speed in bits per second. {+A
      value of zero indicates that the speed is indeterminable, or there
      is no physical point to point link.+}

#6 Reliable transport optimizations (wdiff)

Section 5.8

   The last received message number, Nr, is used to acknowledge messages
   received by an L2TP peer. It contains the sequence number of the
   message the peer expects to receive next (e.g. the last Ns of a non-
   ZLB message received plus 1, modulo 65536).  While the Nr in a
   received ZLB is used to flush messages from the local retransmit
   queue (see below), Nr of the next message sent is not be updated by
   the Ns of the ZLB. {+As a precaution, Nr should be sanity checked
   before flushing the retransmit queue. e.g. if the Nr received in a
   control message is greater than the last Ns sent plus 1 modulo 65536,
   it is clearly invalid.+}

   The reliable transport at a receiving peer is responsible for making
   sure that control messages are delivered in order and without
   duplication to the upper level. Messages arriving out of order may be
   queued for in-order delivery when the missing messages are received,
   or they may be discarded requiring a retransmission by the peer. {+When
   dropping out of order control packets, Nr MAY be updated before the
   packet is discarded.+}

#7 New text to help prevent race condition at the LAC between receipt
of an SLI and application to the data packets. Further, the SLI MUST now
be sent to the LAC if PPP renegotiation occurs at the LNS (actual text).

6.14 Set-Link-Info (SLI)

   The Set-Link-Info message is an L2TP control message sent by the LNS
   to the LAC after the last LCP Conf ACK is received during PPP LCP
   negotation. This AVP contains any relevant link level parameters that
   the LAC may need to be aware of (for instance, ACCM map info). If
   there is no relevant information to be sent in the SLI, then it MAY
   be omitted.  Since LCP may be renegotiated at any time, an SLI may be
   sent at any time during the life of the call, thus the LAC MUST be
   able to update its internal call information and behavior on an
   active session.  Further, if there are packets in queue at the LAC
   when an SLI is received, these must be flushed before applying the
   SLI information to the link.

   If the PPP session at the LNS renegotiates LCP during the call, an
   SLI MUST be sent to the LAC to return link level information to the
   initial default values while the negotiation occurs. However, if the
   last SLI sent was already set to default values or no SLI was sent at
   all, this step MAY be omitted.

#8 Relaxed requirements for IANA. Most of these are a change from requiring IETF Consensus, 
which requires us to wait until the RFC itself is about to be issued (e.g. after last call
and IESG review) to Expert Review, where the IESG identifies someone (such as an 
Editor or WG chair) to give the OK to obtain a value for IANA (actual text).  

10.1 AVP Attributes

   As defined in section 4.1, AVPs contain vendor ID, Attribute and
   Value fields. For vendor ID value of 0, IANA will maintain a registry
   of assigned Attributes and in some case also values. Attributes 0-39
   are assigned as defined in section 4.4. The remaining values are
   available for assignment upon Expert Review [RFC 2434].

10.2 Message Type AVP Values

   As defined in section 4.4.1, Message Type AVPs (Attribute Type 0)
   have an associated value maintained by IANA. Values 0-16 are defined
   in section 3.2, the remaining values are available for assignment
   upon Expert Review [RFC 2434]

10.3 Result Code AVP Values

   As defined in section 4.4.2, Result Code AVPs (Attribute Type 1)
   contain three fields.  Two of these fields (the Result Code and Error
   Code fields) have associated values maintained by IANA.

10.3.1 Result Code Field Values

   The Result Code AVP may be included in CDN and StopCCN messages. The
   allowable values for the Result Code field of the AVP differ
   depending upon the value of the Message Type AVP.  For the StopCCN
   message, values 0-7 are defined in section 4.4.2; for the CDN
   message, values 0-11 are defined in the same section.  The remaining
   values of the Result Code field for both messages are available for
   assignment upon Expert Review [RFC 2434].

10.3.2 Error Code Field Values

   Values 0-7 are defined in section 4.4.2.  Remaining values are
   available for assignment upon Expert Review [RFC 2434].

10.4 Framing Capabilities & Bearer Capabilities

   The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in
   section 4.4.3) both contain 32-bit bitmasks. Additional bits should
   only be defined via a Standards Action [RFC 2434].

10.5 Proxy Authen Type AVP Values

   The Proxy Authen Type AVP (Attribute Type 29) has an associated value
   maintained by IANA. Values 0-5 are defined in section 4.4.5, the
   remaining values are available for assignment upon Expert Review [RFC
   2434].

10.6 AVP Header Bits

   There are four remaining reserved bits in the AVP header. Additional
   bits should only be assigned via a Standards Action [RFC 2434].