tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6320

 
 
 

Protocol for Access Node Control Mechanism in Broadband Networks

Part 2 of 4, p. 10 to 37
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 10 
3.  Access Node Control Protocol -- General Aspects

   This section specifies aspects of the Access Node Control Protocol
   (ANCP) that are generally applicable.

3.1.  Protocol Version

   ANCP messages contain an 8-bit protocol version field.  For the
   protocol version specified in this document, the value of that field
   MUST be set to 50.

3.2.  ANCP Transport

   This document specifies the use of TCP / IPsec+IKEv2 / IP for
   transport of ANCP messages.  For further discussion of the use of
   IPsec and IKEv2, see Section 11.  The present section deals with the
   TCP aspects.  Other specifications may introduce additional
   transports in the future.

      In the case of ATM access, a separate permanent virtual circuit
      (PVC) that is a control channel and is capable of transporting IP
      MAY be configured between the NAS and the AN for ANCP messages.

      In the case of an Ethernet access/aggregation network, a typical
      practice is to send the Access Node Control Protocol messages over
      a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN
      identifier (VLAN ID).

   When transported over TCP, ANCP messages MUST use an encapsulation
   consisting of a 4-byte header field prepended to the ANCP message as
   shown in Figure 3.

Top      Up      ToC       Page 11 
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Identifier (0x880C)        |           Length              |
      |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         ANCP Message                          ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 3: Encapsulation of ANCP Messages over TCP/IP

   The fields of the encapsulating header are as follows:

   Identifier (16 bits):  This identifies a GSMP or ANCP message.  It
      MUST be set to 0x880C.

   Length (16 bits):  Total length of the ANCP message in bytes, not
      including the 4-byte encapsulating header.

   The Access Node MUST initiate the TCP session to the NAS, using
   destination port 6068.

      This is necessary to avoid static address provisioning on the NAS
      for all the ANs that are being served by the NAS.  It is easier to
      configure a given AN with the single IP address of the NAS that
      serves the AN.

   The NAS MUST listen on port 6068 for incoming connections from the
   Access Nodes.

   In the event of an ANCP transport protocol failure, all pending ANCP
   messages destined to the disconnected recipient SHOULD be discarded
   until the transport connection is re-established.

3.3.  Encoding of Text Fields

   In ANCP, all text fields use UTF-8 encoding [RFC3629].  Note that US-
   ASCII characters have the same representation when coded as UTF-8 as
   they do when coded according to [US_ASCII].

   When extracting text fields from a message, the ANCP agent MUST NOT
   assume that the fields are zero-terminated.

Top      Up      ToC       Page 12 
3.4.  Treatment of Reserved and Unused Fields

   ANCP messages contain a number of fields that are unused or reserved.
   Some fields are always unused (typically because they were inherited
   from GSMPv3 but are not useful in the ANCP context).  Others are
   reserved in the current specification, but are provided for
   flexibility in future extensions to ANCP.  Both reserved and unused
   fields MUST be set to zeroes by the sender and MUST be ignored by the
   receiver.

   Unused bits in a flag field are shown in figures as 'x'.  The above
   requirement (sender set to zero, receiver ignore) applies to such
   unused bits.

3.5.  The ANCP Adjacency Protocol

   ANCP uses the adjacency protocol to synchronize the NAS and Access
   Nodes and maintain the ANCP session.  After the TCP connection is
   established, adjacency protocol messages MUST be exchanged as
   specified in this section.  ANCP messages other than adjacency
   protocol messages MUST NOT be sent until the adjacency protocol has
   achieved synchronization.

3.5.1.  ANCP Adjacency Message Format

   The ANCP adjacency message format is shown in Figure 4 below.

Top      Up      ToC       Page 13 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Version   | Message Type  |     Timer     |M|     Code    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Sender Name                          |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                         Receiver Name                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Sender Port                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Receiver Port                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PType |P Flag |               Sender Instance                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |              Receiver Instance                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved      | # of Caps     | Total Length                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                   Capability Fields                           ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: ANCP Adjacency Message Format

   The fields of the ANCP adjacency message are as follows:

   Version (8 bits):  ANCP version, which is subject to negotiation.
      This is the key parameter by means of which ANCP messages can be
      distinguished from GSMP messages received over the same port.

   Message Type (8 bits):  Always has value 10 (adjacency protocol).

   Timer (8 bits):  The Timer field is used to negotiate the timer value
      used in the adjacency protocol with the peer.  The timer specifies
      the nominal time between periodic adjacency protocol messages.  It
      is a constant for the duration of an ANCP session.  The Timer
      field is specified in units of 100 ms, with a default value of 250
      (i.e., 25 seconds).

   M flag (1 bit):  Used in the SYN message to prevent the NAS from
      synchronizing with another NAS and the AN from synchronizing with
      another AN.  In the SYN message, it is always set to 1 by the NAS
      and to 0 by the AN.  In other adjacency message types, it is
      always set to 0 by the sender and ignored by the receiver.

Top      Up      ToC       Page 14 
   Code (7 bits):  The adjacency protocol message type.  It MUST have
      one of the following values:

         Code = 1: SYN;

         Code = 2: SYNACK;

         Code = 3: ACK;

         Code = 4: RSTACK.

   Sender Name (48 bits):  For the SYN, SYNACK, and ACK messages, is the
      identifier of the entity sending the message.  The Sender Name is
      a 48-bit quantity that is unique within the operational context of
      the device.  A 48-bit IEEE 802 Media Access Control (MAC) address,
      if available, may be used for the Sender Name.  If the Ethernet
      encapsulation is used, the Sender Name MUST be the Source Address
      from the MAC header.  For the RSTACK message, the Sender Name
      field is set to the value of the Receiver Name field from the
      incoming message that caused the RSTACK message to be generated.

   Receiver Name (48 bits)  For the SYN, SYNACK, and ACK messages, is
      the name of the entity that the sender of the message believes is
      at the far end of the link.  If the sender of the message does not
      know the name of the entity at the far end of the link, this field
      SHOULD be set to zero.  For the RSTACK message, the Receiver Name
      field is set to the value of the Sender Name field from the
      incoming message that caused the RSTACK message to be generated.

   Sender Port (32 bits):  For the SYN, SYNACK, and ACK messages, is the
      local port number of the link across which the message is being
      sent.  For the RSTACK message, the Sender Port field is set to the
      value of the Receiver Port field from the incoming message that
      caused the RSTACK message to be generated.

   Receiver Port (32 bits):  For the SYN, SYNACK, and ACK messages, is
      what the sender believes is the local port number for the link,
      allocated by the entity at the far end of the link.  If the sender
      of the message does not know the port number at the far end of the
      link, this field SHOULD be set to zero.  For the RSTACK message,
      the Receiver Port field is set to the value of the Sender Port
      field from the incoming message that caused the RSTACK message to
      be generated.

   PType (4 bits):  PType is used to specify if partitions are used and
      how the Partition ID is negotiated.

Top      Up      ToC       Page 15 
         Type of partition being requested:

         0 - no partition;

         1 - fixed partition request;

         2 - fixed partition assigned.

   P Flag (4 bits):  Used to indicate the type of partition request.

         1 - new adjacency;

         2 - recovered adjacency.

      In case of a conflict between the peers' views of the value of the
      P Flag, the lower value is used.

   Sender Instance (24 bits):  For the SYN, SYNACK, and ACK messages, is
      the sender's instance number for the link to the peer.  It is used
      to detect when the link comes back up after going down or when the
      identity of the entity at the other end of the link changes.  The
      instance number is a 24-bit number that is guaranteed to be unique
      within the recent past and to change when the link or node comes
      back up after going down.  Zero is not a valid instance number.
      For the RSTACK message, the Sender Instance field is set to the
      value of the Receiver Instance field from the incoming message
      that caused the RSTACK message to be generated.

   Partition ID (8 bits):  Field used to associate the message with a
      specific partition of the AN.  The value of this field is
      negotiated during the adjacency procedure.  The AN makes the final
      decision, but will consider a request from the NAS.  If the AN
      does not support partitions, the value of this field MUST be 0.
      Otherwise, it MUST be non-zero.

   Receiver Instance (24 bits):  For the SYN, SYNACK, and ACK messages,
      is what the sender believes is the current instance number for the
      link, allocated by the entity at the far end of the link.  If the
      sender of the message does not know the current instance number at
      the far end of the link, this field SHOULD be set to zero.  For
      the RSTACK message, the Receiver Instance field is set to the
      value of the Sender Instance field from the incoming message that
      caused the RSTACK message to be generated.

   Reserved (8 bits):  Reserved for use by a future version of this
      specification.

Top      Up      ToC       Page 16 
   # of Caps (8 bits):  Indicates the number of Capability fields that
      follow.

   Total Length (16 bits):  Indicates the total number of bytes occupied
      by the Capability fields that follow.

   Capability Fields:  Each Capability field indicates one ANCP
      capability supported by the sender of the adjacency message.
      Negotiation of a common set of capabilities to be supported within
      the ANCP session is described below.  The detailed format of a
      Capability field is shown in Figure 5 and described below.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Capability Type           |   Capability Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                                                               ~
      ~                   Capability Data                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 5: Capability Field

   The sub-fields of this structure are as follows:

   Capability Type (16 bits):  Indicates the specific capability
      supported.  An IANA registry exists for values of this sub-field.
      The values specified by this document are listed below.

   Capability Length (16 bits):  The number of bytes of data contained
      in the Capability Data sub-field, excluding padding.  If the
      definition of a particular capability includes no capability data,
      the value of the Capability Length sub-field is zero.

   Capability Data (as indicated by Capability Length):  Contains data
      associated with the capability as specified for that capability.
      If the definition of a particular capability includes no
      capability data, the Capability Data sub-field is absent (has zero
      length).  Otherwise, the Capability Data sub-field MUST be padded
      with zeroes as required to terminate on a 4-byte word boundary.
      The possibility of specifying capability data provides the
      flexibility to advertise more than the mere presence or absence of
      a capability if needed.

Top      Up      ToC       Page 17 
   The following capabilities are defined for ANCP as applied to DSL
   access:

   o  Capability Type: DSL Topology Discovery = 0x01

         Access technology: DSL

         Length (in bytes): 0

         Capability Data: NULL

      For the detailed protocol specification of this capability, see
      Section 6.

   o  Capability Type: DSL Line Configuration = 0x02

         Access technology: DSL

         Length (in bytes): 0

         Capability Data: NULL

      For the detailed protocol specification of this capability, see
      Section 7.

   o  Capability Type: DSL Remote Line Connectivity Testing = 0x04

         Access technology: DSL

         Length (in bytes): 0

         Capability Data: NULL

      For the detailed protocol specification of this capability, see
      Section 8.

   In addition to the adjacency messages whose format is shown in
   Figure 6, ANCP adjacency procedures use the Adjacency Update message
   (Figure 6) to inform other NASs controlling the same AN partition
   when a particular NAS joins or loses an adjacency with that
   partition.

Top      Up      ToC       Page 18 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    | Message Type  | Result|        Code           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |            Transaction Identifier             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|      SubMessage Number      |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: The Adjacency Update Message

   The Adjacency Update message is identical to the general ANCP message
   header described in Section 3.6, but the field settings are in part
   specific to the Adjacency Update message.  The fields in this message
   are as follows:

   Version (8 bits):  The ANCP version negotiated and running in this
      adjacency.

   Message Type (8 bits):  Always 85.

   Result (4 bits):  Set to Ignore (0).

   Code (12 bits):  Set to the total number of adjacencies currently
      established on this partition, from the point of view of the AN.

   Partition ID (8 bits):  The partition identifier of the partition for
      which this notification is being sent.

   Transaction Identifier (24 bits):  MUST be set to 0.

   I (1 bit), SubMessage number (15 bits):  Set as described in
      Section 3.6.1.7.

   Length (16 bits):  Set as described in Section 3.6.1.8.

3.5.2.  ANCP Adjacency Procedures

3.5.2.1.  Overview

   The ANCP adjacency protocol operates symmetrically between the NAS
   and the AN.  In the absence of errors or race conditions, each peer
   sends a SYN message, receives a SYNACK message in acknowledgement,
   and completes the establishment of the adjacency by sending an ACK
   message.  Through this exchange, each peer learns the values of the
   Name, Port, and Instance parameters identifying the other peer, and

Top      Up      ToC       Page 19 
   the two peers negotiate the values of the Version, Timer, P Flag, and
   Partition ID parameters and the set of capabilities that the
   adjacency will support.

   Once the adjacency has been established, its liveness is periodically
   tested.  The peers engage in an ACK message exchange at a frequency
   determined by the negotiated value of the Timer field.

   If an inconsistency, loss of contact, or protocol violation is
   detected, the detecting peer can force a restart of the
   synchronization process by sending an RSTACK message to the other
   end.

   Once an adjacency has been established, if more than one NAS has
   established an adjacency to the same partition, then the AN sends an
   Adjacency Update message to each such NAS to let it know how many
   established adjacencies the partition currently supports.  Similarly,
   if an adjacency is lost, the AN sends an Adjacency Update message to
   each of the remaining adjacent NASs to let them know about the change
   in status.

3.5.2.2.  Adjacency Protocol State Machine

   The adjacency protocol is described by the following rules and state
   tables.  It begins with the sending of a SYN by each end as soon as
   the transport connection has been established.  If at any point the
   operations A, B, C, or "Verify Adjacent State" defined below detect a
   mismatch, a log SHOULD be generated, identifying the fields concerned
   and the expected and received values for each.

   The rules and state tables use the following operations:

   o  The "Record Adjacency State" operation is defined in
      Section 3.5.2.3.2.

   o  The "Verify Adjacency State" operation consists of verifying that
      the contents of the incoming SYNACK message match the adjacency
      state values previously recorded.

   o  The procedure "Reset the link" is defined as:

      1.  Generate a new instance number for the link.

      2.  Delete the peer verifier (set to zero the values of Sender
          Instance, Sender Port, and Sender Name previously stored by
          the "Record Adjacency State" operation).

      3.  Send a SYN message (Section 3.5.2.3.1).

Top      Up      ToC       Page 20 
      4.  Enter the SYNSENT state.

   o  The state tables use the following Boolean terms and operators.

      A.  The Sender Instance in the incoming message matches the value
          stored from a previous message by the "Record Adjacency State"
          operation.

      B.  The Sender Instance, Sender Port, Sender Name, and Partition
          ID fields in the incoming message match the values stored from
          a previous message by the "Record Adjacency State" operation.

      C.  The Receiver Instance, Receiver Port, Receiver Name, and
          Partition ID fields in the incoming message match the values
          of the Sender Instance, Sender Port, Sender Name, and
          Partition ID currently sent in outgoing SYN, SYNACK, and ACK
          messages, except that the NAS always accepts the Partition ID
          value presented to it in a SYN or SYNACK message.

         "&&" Represents the logical AND operation.

         "||" Represents the logical OR operation.

         "!"  Represents the logical negation (NOT) operation.

   o  A timer is required for the periodic generation of SYN, SYNACK,
      and ACK messages.  The value of the timer is negotiated in the
      Timer field.  The period of the timer is unspecified, but a value
      of 25 seconds is suggested.  Note that since ANCP uses a reliable
      transport protocol, the timer is unlikely to expire in any state
      other than ESTAB.

      There are two independent events: the timer expires, and a packet
      arrives.  The processing rules for these events are:

         Timer Expires: Reset Timer

            If state = SYNSENT Send SYN

            If state = SYNRCVD Send SYNACK

            If state = ESTAB Send ACK

Top      Up      ToC       Page 21 
         Packet Arrives:

            If incoming message is an RSTACK:

               If (A && C && !SYNSENT) Reset the link

               Else discard the message.

            If incoming message is a SYN, SYNACK, or ACK:

               Response defined by the following state tables.

            If incoming message is any other ANCP message and state !=
            ESTAB:

               Discard incoming message.

               If state = SYNSENT Send SYN (Note 1)

               If state = SYNRCVD Send SYNACK (Note 1)

         Note 1: No more than two SYN or SYNACK messages should be sent
         within any time period of length defined by the timer.

   o  State synchronization across a link is considered to be achieved
      when the protocol reaches the ESTAB state.  All ANCP messages,
      other than adjacency protocol messages, that are received before
      synchronization is achieved will be discarded.

3.5.2.2.1.  State Tables

    State: SYNSENT

   +===================================================================+
   |    Condition    |                Action               | New State |
   +=================+=====================================+===========+
   |   SYNACK && C   |  Update Peer Verifier; Send ACK     |   ESTAB   |
   +-----------------+-------------------------------------+-----------+
   |   SYNACK && !C  |            Send RSTACK              |  SYNSENT  |
   +-----------------+-------------------------------------+-----------+
   |       SYN       |  Update Peer Verifier; Send SYNACK  |  SYNRCVD  |
   +-----------------+-------------------------------------+-----------+
   |       ACK       |            Send RSTACK              |  SYNSENT  |
   +===================================================================+

Top      Up      ToC       Page 22 
    State: SYNRCVD

   +===================================================================+
   |    Condition    |                Action               | New State |
   +=================+=====================================+===========+
   |   SYNACK && C   |  Verify Adjacency State; Send ACK   |   ESTAB   |
   +-----------------+-------------------------------------+-----------+
   |   SYNACK && !C  |            Send RSTACK              |  SYNRCVD  |
   +-----------------+-------------------------------------+-----------+
   |       SYN       | Record Adjacency State; Send SYNACK |  SYNRCVD  |
   +-----------------+-------------------------------------+-----------+
   |  ACK && B && C  |              Send ACK               |   ESTAB   |
   +-----------------+-------------------------------------+-----------+
   | ACK && !(B && C)|            Send RSTACK              |  SYNRCVD  |
   +===================================================================+


    State: ESTAB

   +===================================================================+
   |    Condition    |                Action               | New State |
   +=================+=====================================+===========+
   |  SYN || SYNACK  |           Send ACK (Note 2)         |   ESTAB   |
   +-----------------+-------------------------------------+-----------+
   |  ACK && B && C  |           Send ACK (Note 3)         |   ESTAB   |
   +-----------------+-------------------------------------+-----------+
   | ACK && !(B && C)|              Send RSTACK            |   ESTAB   |
   +===================================================================+

   Note 2: No more than two ACKs should be sent within any time period
   of length defined by the timer.  Thus, one ACK MUST be sent every
   time the timer expires.  In addition, one further ACK may be sent
   between timer expirations if the incoming message is a SYN or SYNACK.
   This additional ACK allows the adjacency protocol to reach
   synchronization more quickly.

   Note 3: No more than one ACK should be sent within any time period of
   length defined by the timer.

3.5.2.3.  The Adjacency Protocol SYN Message

3.5.2.3.1.  Action by the Sender

   The SYN message is sent in accordance with the state tables just
   described.  The sender sets the individual fields as follows:

Top      Up      ToC       Page 23 
   Version:  SHOULD be set to the highest version of ANCP that the
      sender supports.

   Message Type:  MUST be set to 10.

   Timer:  SHOULD be set to the value configured in the AN or NAS
      sending the message.

   M Flag:  MUST be set to 1 by the NAS, and 0 by the AN.

   Code:  MUST be set to 1 (SYN).

   Sender Name:  Set as described in Section 3.5.1.

   Receiver Name:  SHOULD be set to 0.

   Sender Port:  Set as described in Section 3.5.1.

   Receiver Port:  SHOULD be set to 0.

   PType:  Set according to the following rules:

         Settings by the AN:

            0 - the AN does not support partitions;

            2 - the value of Partition ID contained in this message is
            assigned to the current partition.

         Settings by the NAS:

            0 - the NAS leaves the decision on partitioning to the AN
            (RECOMMENDED setting);

            1 - the NAS requests that the AN use the value of Partition
            ID contained in this message for the current partition.  The
            NAS MAY use this setting even if it has already received a
            SYN message from the AN, provided that the AN has indicated
            support for partitions.  The NAS MUST be prepared to use
            whatever value it receives in a subsequent SYN or SYNACK
            message, even if this differs from the requested value.

   P Flag:  Set to the mode of adjacency setup (new adjacency vs.
      recovered adjacency) requested by the sender.  Warning: setting P
      Flag=1 runs the risk of state mismatch because ANCP does not
      provide the means for the NAS to audit the current state of the
      AN.

Top      Up      ToC       Page 24 
   Sender Instance:  Set as described in Section 3.5.1.

   Partition ID:  MUST be set to 0 if PType=0; otherwise, set to the
      assigned or requested partition identifier value.

   Receiver Instance:  SHOULD be set to 0.

   # of Caps:  MUST be set to the number of Capability fields that
      follow.

   Total Length:  MUST be set to the total number of bytes in the
      Capability fields that follow.

   Capability Fields:  One Capability field MUST be present for each
      ANCP capability for which the sender wishes to advertise support.

3.5.2.3.2.  Action by the Receiver

   Upon receiving a validly formed SYN message, the receiver first
   checks the value of the Version field.  If this value is not within
   the range of ANCP versions that the receiver supports, the message
   MUST be silently ignored.  Similarly, the message is silently ignored
   if the M flag is 0 and the receiver is an AN or if the M flag is 1
   and the receiver is a NAS.  If these checks are passed and the
   receiver is in ESTAB state, it returns an ACK (as indicated by the
   ESTAB state table in Section 3.5.2.2.1).  The contents of the ACK
   MUST reflect the adjacency state as previously recorded by the
   receiver.

   Otherwise, the receiver MUST perform the "Record Adjacency State"
   operation by recording the following fields:

   Version:  The supported Version value received in the SYN message.
      This value MUST be used for all subsequent ANCP messages sent
      during the life of the adjacency.

   Timer:  The larger of the Timer value received in the SYN message and
      the value with which the receiver is configured.

   Sender Name:  The value of the Sender Name field in the SYN message
      just received.

   Receiver Name:  The value used by the receiver in the Sender Name
      field of SYN, SYNACK, and ACK messages it sends in this adjacency.

Top      Up      ToC       Page 25 
   Sender Port:  The value of the Sender Port field in the SYN message
      just received.

   Receiver Port:  The value used by the receiver in the Sender Port
      field of SYN, SYNACK, and ACK messages it sends in this adjacency.

   Sender Instance:  The value of the Sender Instance field in the SYN
      message just received.

   P Flag:  The lesser of the value determined by local policy and the
      value received in the SYN message.  That is, preference is given
      to "0 - New adjacency" if there is a conflict.

   Partition ID:  If the SYN receiver is the AN, this is set to 0 if the
      AN does not support partitions or to the non-zero value of the
      partition identifier it chooses to assign otherwise.  If the SYN
      receiver is the NAS, this is set to the value of the Partition ID
      field copied from the SYN.

   Receiver Instance:  The value used by the receiver in the Sender
      Instance field of SYN, SYNACK, and ACK messages it sends in this
      adjacency.

   Capabilities:  The set of ANCP capabilities that were offered in the
      SYN and are supported by the receiver.

3.5.2.4.  The Adjacency Protocol SYNACK Message

3.5.2.4.1.  Action by the Sender

   The SYNACK is sent in response to a successfully received SYN
   message, as indicated by the state tables.  The Version, Timer, P
   Flag, and Partition ID fields MUST be populated with the values
   recorded as part of adjacency state.  The # of Caps, Total Length,
   and Capability fields MUST also be populated in accordance with the
   Capabilities recorded as part of adjacency state.  The remaining
   fields of the SYNACK message MUST be populated as follows:

   Message Type:  MUST be 10.

   M flag:  MUST be set to 0.

   Code:  MUST be 2 (SYNACK).

   PType:  MUST be 0 if the Partition ID value is 0 or 2 if the
      Partition ID value is non-zero.

Top      Up      ToC       Page 26 
   Sender Name:  MUST be set to the Receiver Name value recorded as part
      of adjacency state.

   Receiver Name:  MUST be set to the Sender Name value recorded as part
      of adjacency state.

   Sender Port:  MUST be set to the Receiver Port value recorded as part
      of adjacency state.

   Receiver Port:  MUST be set to the Sender Port value recorded as part
      of adjacency state.

   Sender Instance:  MUST be set to the Receiver Instance value recorded
      as part of adjacency state.

   Receiver Instance:  MUST be set to the Sender Instance value recorded
      as part of adjacency state.

   If the set of capabilities recorded in the adjacency state is empty,
   then after sending the SYNACK the sender MUST raise an alarm to
   management, halt the adjacency procedure, and tear down the TCP
   session if it is not being used by another adjacency.  The sender MAY
   also terminate the IPsec security association if no other adjacency
   is using it.

3.5.2.4.2.  Action by the Receiver

   As indicated by the state tables, the receiver of a SYNACK first
   checks that the Receiver Name, Receiver Port, and Receiver Instance
   values match the Sender Name, Sender Port, and Sender Instance values
   it sent in SYN message that is being acknowledged.  The AN also
   checks that the PType and Partition ID match.  If any of these checks
   fail, the receiver sends an RSTACK as described in Section 3.5.2.6.1.

   The receiver next checks whether the set of capabilities provided in
   the SYNACK is empty.  If so, the receiver MUST raise an alarm to
   management and halt the adjacency procedure.

   Assuming that the SYNACK passes these checks, two cases arise.  The
   first possibility is that the receiver has already recorded adjacency
   state.  This will occur if the SYNACK is received while the receiver
   is in SYNRCVD state.  In this case, the Version, Timer, Sender Name,
   Sender Port, Sender Instance, P Flag, and capability-related fields
   in the SYNACK MUST match those recorded as part of adjacency state.
   If a mismatch is detected, the receiver sends an RSTACK.  This is the
   "Verify Adjacency State" procedure shown in the SYNRCVD state table.

Top      Up      ToC       Page 27 
   If, on the other hand, the SYNACK is received while the receiver is
   in SYNSENT state, the receiver MUST record session state as described
   in Section 3.5.2.3.2.

   In either case, if the receiver is the NAS, it MUST accept the
   Partition ID value provided in the SYNACK, updating its recorded
   adjacency state if necessary.

3.5.2.5.  The Adjacency Protocol ACK Message

3.5.2.5.1.  Actions by the Sender

   As indicated by the state tables, the ACK message is sent in a number
   of different circumstances.  The main-line usages are as a response
   to SYNACK, leading directly to the ESTAB state, and as a periodic
   test of liveness once the ESTAB state has been reached.

   The sender MUST populate the ACK from recorded adjacency state,
   exactly as described in Section 3.5.2.4.1.  The only difference is
   that Code MUST be set to 3 (ACK).

3.5.2.5.2.  Actions by the Receiver

   The required actions by the receiver are specified by the state
   tables.  In addition to the checks B and C, the receiver SHOULD
   verify that the remaining contents of the ACK match the recorded
   adjacency state at the receiver.  If that check fails, the receiver
   MUST send an RSTACK as described in Section 3.5.2.6.1.

   Once the adjacency has been established, either peer can initiate the
   ACK exchange that tests for liveness.  To meet the restrictions on
   ACK frequency laid down in the notes to the state tables, it is
   desirable that only one such exchange occur during any one interval.
   Hence, if a peer receives an ACK when in ESTAB state, it MUST reply
   to that ACK as directed by the state tables, but SHOULD NOT initiate
   another ACK exchange in the same interval.  To meet this objective,
   the receiver MUST reset its timer when it receives an ACK while in
   ESTAB state.

      It is, of course, possible that two exchanges happen because of
      race conditions.

Top      Up      ToC       Page 28 
3.5.2.6.  The Adjacency Protocol RSTACK Message

3.5.2.6.1.  Action by the Sender

   The RSTACK is sent in response to various error conditions as
   indicated by the state tables.  In general, it leads to a restart of
   adjacency negotiations (although this takes a few steps when the
   original sender of the RSTACK is in ESTAB state).

   As indicated in Section 3.5.1, the Sender Name, Port, and Instance
   fields in the RSTACK MUST be copied from the Receiver, Name, Port,
   and Instance fields in the message that caused the RSTACK to be sent.
   Similarly, the Receiver identifier fields in the RSTACK MUST be
   copied from the corresponding Sender identifier fields in the message
   that triggered the RSTACK.

   If the sender has recorded adjacency state, the Version, Timer,
   PType, P Flag, Partition ID, and capability-related fields SHOULD be
   set based on the recorded adjacency state.  Otherwise, they SHOULD be
   the same as the sender would send in a SYN message.  The Message Type
   MUST be 10, the M flag MUST be 0, and Code MUST be 4 (RSTACK).

3.5.2.6.2.  Action by the Receiver

   The receiver of an RSTACK MAY attempt to diagnose the problem that
   caused the RSTACK to be generated by comparing its own adjacency
   state with the contents of the RSTACK.  However, the primary purpose
   of the RSTACK is to trigger action as prescribed by Section 3.5.2.2.

3.5.2.7.  Loss of Synchronization

   Loss of synchronization MAY be declared if after synchronization is
   achieved:

   o  no valid ANCP messages are received in any period of time in
      excess of three times the value of the Timer field negotiated in
      the adjacency protocol messages, or

   o  a mismatch in adjacency state is detected.

   In either case, the peer detecting the condition MUST send an RSTACK
   to the other peer, as directed in Section 3.5.2.6.1, in order to
   initiate resynchronization.

   While re-establishing synchronization with a controller, a switch
   SHOULD maintain its connection state, deferring the decision about
   resetting the state until after synchronization is re-established.

Top      Up      ToC       Page 29 
   Once synchronization is re-established, the decision about resetting
   the connection state SHOULD be made based on the negotiated value of
   the P Flag.

3.6.  ANCP General Message Formats

   This section describes the general format of ANCP messages other than
   the adjacency messages.  See Figure 7.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    | Message Type  | Result|      Result Code      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |            Transaction Identifier             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|      SubMessage Number      |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                          Message Payload                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 7: ANCP General Message Format

3.6.1.  The ANCP Message Header

   A complete explanation of the ANCP general message header fields
   follows.

3.6.1.1.  Version Field (8 bits)

   This field carries the version of ANCP that was agreed upon for the
   session during adjacency negotiation.

3.6.1.2.  Message Type Field (8 bits)

   This field indicates the ANCP message type.  Message type values are
   registered in an IANA registry.

3.6.1.3.  Result Field (4 bits)

   In request messages, the Result field indicates the circumstances
   under which a response is required.  ANCP specifies what Result value
   each request message type should have.  In responses, the Result
   field indicates either Success (0x3) or Failure (0x4), as the case
   may be.

Top      Up      ToC       Page 30 
   Ignore:  Res = 0x0 - Treat this field as a "no operation" and follow
      the response procedures specified for the received message type.

   Nack:  Res = 0x1 - Result value indicating that a response is
      expected to the request only in cases of failure caused during the
      processing of the message contents or of the contained
      directive(s).

   AckAll:  Res = 0x2 - Result value indicating that a response to the
      message is requested in all cases.

   Success:  Res = 0x3 - Result value indicating that this is a response
      and that the request was executed successfully.  The Result Code
      field for a successful result is typically 0, but it MAY take on
      other values as specified for particular message types.

   Failure:  Res = 0x4 - Result value indicating that this is a response
      and that the request was not executed successfully.  The receiver
      of the response SHOULD take further action as indicated by the
      Result Code value and any diagnostic data contained in a Status-
      Info TLV included in the response.

3.6.1.4.  Result Code Field (12 bits)

   This field gives further information concerning the result in a
   response message.  It is mostly used to pass an error code in a
   failure response, but it can also be used to give further information
   in a success response message or an event message.  In a request
   message, the Result Code field is not used and MUST be set to 0x0 (No
   result).

   A number of Result Code values are specified below.  Specification of
   additional Result Code values in extensions or updates to this
   document MUST include the following information:

   o  Result Code value;

   o  One-line description;

   o  Where condition detected (control application or ANCP agent);

   o  Further description (if any);

   o  Required additional information in the response message;

   o  Target (control application or ANCP agent at the peer that sent
      the original request);

Top      Up      ToC       Page 31 
   o  Action RECOMMENDED for the receiving ANCP agent.

   In addition to any suggested action in the text that follows, a count
   of the number of times a given non-zero Result Code value was
   received SHOULD be provided for management.  Where an action includes
   the re-sending of a request, a given request SHOULD NOT be re-sent
   more than once.

   This document specifies the following Result Code values.

   Result Code value: 0x2

      *  One-line description: Invalid request message

      *  Where condition detected: ANCP agent

      *  Further description: The request was a properly formed message
         that violates the protocol through its timing or direction of
         transmission.  The most likely reason for this outcome in the
         field will be a race condition.

      *  Required additional information in the response message: None,
         if the response message is of the same type as the request.  As
         specified in Section 4.2, if the response message is a Generic
         Response message.

      *  Target: ANCP agent at the peer that sent the original request

      *  Action RECOMMENDED for the receiving ANCP agent: The original
         request MAY be re-sent once only after a short delay.  Inform
         the control application with appropriate identification of the
         failed transaction if the second attempt fails or no second
         attempt is made.

   Result Code value: 0x6

      *  One-line description: One or more of the specified ports are
         down

      *  Where condition detected: Control application

      *  Further description (if any): This Result Code value indicates
         a state mismatch between the NAS and AN control applications,
         possibly due to a race condition.

Top      Up      ToC       Page 32 
      *  Required additional information in the response message: If the
         request identified multiple access lines or the response is a
         Generic Response message, then the response MUST contain a
         Status-Info TLV encapsulating TLV(s) containing the line
         identifier(s) of the access lines that are not operational.

      *  Target: Control application at the peer that sent the original
         request

      *  Action RECOMMENDED for the receiving ANCP agent: Indicate the
         error and forward the line identifier(s) to the control
         application.

   Result Code value: 0x13

      *  One-line description: Out of resources

      *  Where condition detected: ANCP protocol layer or control
         application

      *  Further description (e.g., memory exhausted): This Result Code
         value MUST be reported only by the AN, and indicates a
         condition that is probably unrelated to specific access lines
         (although it may be related to the specific request).

      *  Required additional information in the response message: None,
         if the response message is of the same type as the request.  As
         specified in Section 4.2, if the response message is a Generic
         Response message.

      *  Target: ANCP agent at the peer that sent the original request

      *  Action RECOMMENDED for the receiving ANCP agent: If the NAS
         receives this Result Code value from multiple requests for the
         same AN in a short interval, it SHOULD reduce the rate at which
         it sends requests in proportion to the rate at which requests
         are failing with Result Code = 19.  It MAY retry individual
         requests.  If only a specific request is failing with Result
         Code = 19, the ANCP agent in the NAS MAY request the control
         application to decompose the request into simpler components if
         this is possible.

   Result Code value: 0x51

      *  One-line description: Request message type not implemented

      *  Where condition detected: ANCP agent

Top      Up      ToC       Page 33 
      *  Further description: This could indicate a mismatch in protocol
         version or capability state.  It is also possible that support
         of a specific message is optional within some ANCP capability.

      *  Required additional information in the response message: None,
         if the response message is of the same type as the request.  As
         specified in Section 4.2, if the response message is a Generic
         Response message.

      *  Target: ANCP agent at the peer that sent the original request

      *  Action RECOMMENDED for the receiving ANCP agent: If the
         receiver of this Result Code value expects that support of the
         message type concerned is mandatory according to the
         capabilities negotiated for the session, it MAY re-send the
         message in case the message was corrupted in transit the first
         time.  If that fails, and use of the message type cannot be
         avoided, the ANCP agent MAY reset the adjacency by sending an
         RSTACK adjacency message as described in Section 3.5.2.6.1,
         where Sender and Receiver Name, Port, and Instance are taken
         from recorded adjacency state.  If a reset does not eliminate
         the problem, the receiving ANCP agent SHOULD raise an alarm to
         management and then cease to operate.

   Result Code value: 0x53

      *  One-line description: Malformed message

      *  Where condition detected: ANCP agent

      *  Further description: This could be the result of corruption in
         transit, or an error in implementation at one end or the other.

      *  Required additional information in the response message: None,
         if the response message is of the same type as the request.  As
         specified in Section 4.2, if the response message is a Generic
         Response message.

      *  Target: ANCP agent at the peer that sent the original request

      *  Action RECOMMENDED for the receiving ANCP agent: The request
         SHOULD be re-sent once to eliminate the possibility of in-
         transit corruption.

   Result Code value: 0x54

      *  One-line description: Mandatory TLV missing

Top      Up      ToC       Page 34 
      *  Where condition detected: ANCP agent

      *  Further description: None

      *  Required additional information in the response message: The
         response message MUST contain a Status-Info message that
         encapsulates an instance of each missing mandatory TLV, where
         the length is set to zero and the value field is empty (i.e.,
         only the 4-byte TLV header is present).

      *  Target: ANCP agent at the peer that sent the original request

      *  Action RECOMMENDED for the receiving ANCP agent: Re-send the
         message with the missing TLV(s), if possible.  Otherwise,
         report the error to the control application with an indication
         of the missing information required to construct the missing
         TLV(s).

   Result Code value: 0x55

      *  One-line description: Invalid TLV contents

      *  Where condition detected: ANCP agent

      *  Further description: The contents of one or more TLVs in the
         request do not match the specifications provided for the those
         TLVs.

      *  Required additional information in the response message: The
         response MUST contain a Status-Info TLV encapsulating the
         erroneous TLVs copied from the original request.

      *  Target: ANCP agent at the peer that sent the original request

      *  Action RECOMMENDED for the receiving ANCP agent: Correct the
         error and re-send the request, if possible.  Otherwise, report
         the error to the control application with an indication of the
         erroneous information associated with the invalid TLV(s).

   Result Code value: 0x500

      *  One-line description: One or more of the specified ports do not
         exist

      *  Where condition detected: Control application

Top      Up      ToC       Page 35 
      *  Further description (if any): This may indicate a configuration
         mismatch between the AN and the NAS or Authentication,
         Authorization, and Accounting (AAA).

      *  Required additional information in the response message: If the
         request identified multiple access lines or the response is a
         Generic Response message, then the response MUST contain a
         Status-Info TLV encapsulating TLV(s) containing the rejected
         line identifier(s).

      *  Target: Control application at the peer that sent the original
         request

      *  Action RECOMMENDED for the receiving ANCP agent: Indicate the
         error and forward the line identifiers to the control
         application.

3.6.1.5.  Partition ID (8 bits)

   The Partition ID field MUST contain the value that was negotiated for
   Partition ID during the adjacency procedure as described above.

3.6.1.6.  Transaction ID (24 bits)

   The Transaction ID is set by the sender of a request message to
   associate a response message with the original request message.
   Unless otherwise specified for a given message type, the Transaction
   ID in request messages MUST be set to a value in the range
   (1, 2^24 - 1).  When used in this manner, the Transaction ID
   sequencing MUST be maintained independently for each message type
   within each ANCP adjacency.  Furthermore, it SHOULD be incremented by
   1 for each new message of the given type, cycling back to 1 after
   running the full range.  For event messages, the Transaction ID
   SHOULD be set to zero.

   Unless otherwise specified, the default behavior for all ANCP
   responses is that the value of the Transaction ID MUST be copied from
   the corresponding request message.

3.6.1.7.  I Flag and SubMessage Number (1 + 15 bits)

   In GSMPv3, these provide a mechanism for message fragmentation.
   Because ANCP uses TCP transport, this mechanism is unnecessary.  An
   ANCP agent MUST set the I Flag and subMessage Number fields to 1 to
   signify "no fragmentation".

Top      Up      ToC       Page 36 
3.6.1.8.  Length (16 bits)

   This field MUST be set to the length of the ANCP message in bytes,
   including its header fields and message body but excluding the 4-byte
   encapsulating header defined in Section 3.2.

3.6.2.  The ANCP Message Body

   The detailed contents of the message payload portion of a given ANCP
   message can vary with the capability in the context of which it is
   being used.  However, the general format consists of zero or more
   fixed fields, followed by a variable amount of data in the form of
   Type-Length-Value (TLV) data structures.

   The general format of a TLV is shown in Figure 8:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type (IANA registered)    |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            Value                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 8: General TLV Format

   The fields of a TLV are defined as follows:

   Type (16 bits):  The TLV Type is an unsigned value identifying the
      TLV type and nature of its contents.  An IANA registry has been
      established for ANCP TLV Type codes.

   Length (16 bits):  The number of bytes of data in the Value field of
      the TLV, excluding any padding required to bring this TLV to a
      4-byte word boundary (see "Value" below).  If a TLV contains other
      TLVs, any padding in the contained TLVs MUST be included in the
      value of Length.  Depending on the specification of the TLV, the
      value of Length can be zero, a constant for all instances of the
      TLV, or a varying quantity.

   Value (variable):  The actual data carried by the TLV, if any.  The
      Value field in each TLV MUST be padded with zeroes as required to
      align with a 4-byte word boundary.  The Value field of a TLV MAY
      include fixed fields and/or other TLVs.

Top      Up      ToC       Page 37 
   Unless otherwise specified, TLVs MAY be added to a message in any
   order.  If the recipient of a message does not understand a
   particular TLV, it MUST silently ignore it.

   A number of TLVs are specified in the remainder of this document.

3.7.  General Principles for the Design of ANCP Messages

   ANCP allows for two messaging constructs to support request/response
   interaction:

   a.  The same message type is used for both the request message and
       the response message.  The Result and Result Code field settings
       are used to differentiate between request and response messages.

   b.  The request and response messages use two different message
       types.

   The first approach is illustrated by the protocol specifications in
   Section 8.4, the second by specifications in Section 6.4.  The
   purpose of this section is to provide more details about the second
   approach in order to allow the use of this messaging construct for
   the development of additional ANCP extensions.

   As Section 3.6 indicated, all ANCP messages other than adjacency
   messages share a common header format.  When the response message
   type is different from that of the request, the specification of the
   request message will typically indicate that the Result field is set
   to Ignore (0x0) and provide procedures indicating explicitly when the
   receiver should generate a response and what message type it should
   use.

   The Transaction ID field is used to distinguish between multiple
   request messages of the same type and to associate a response message
   to a request.  Specifications of ANCP messages for applications not
   requiring response correlation SHOULD indicate that the Transaction
   ID MUST be set to zero in requests.  Applications that require
   response correlation SHOULD refer to the Transaction ID behavior
   described in Section 3.6.1.

   The specification for a response message SHOULD indicate in all cases
   that the value of the Transaction Identifier MUST be set to that of
   the corresponding request message.  This allows the requester to
   establish whether or not correlation is needed (by setting a non-zero
   or zero value for the Transaction ID).


Next RFC Part