Subject: [ANCP] New proposal to clarify our discussion

From: Tom Taylor <[email-masked]>
Date: Sat, 27 Nov 2010 16:19:57 -0500

I have a proposal which will at least clarify our discussion of the 
protocol requirements for ANCP and in particular for the DSL Topology 
Discovery capability. The essence of the proposal is to recognize the 
distinction between ANCP and the control application that uses it.

To start with, we would work the following text into the introduction.

<begin proposed text>

2. Introduction

This document specifies the Access Node Control Protocol (ANCP), which 
is used to exchange control information between the Access Node (AN) and 
the Network Access Server (NAS). The requirements for ANCP and the 
context within which it operates are described in [RFC 5851].

ANCP provides its services to control applications operating in the AN 
and NAS respectively. This relationship is shown in Figure 1. 
Specification of the control applications is beyond the scope of this 
document, but informative partial descriptions are provided as necessary 
to provide a context for the operation of the protocol.

       Access Node                         Network Access Server
   +------------------+                     +------------------+
   | +--------------+ |                     | +--------------+ |
   | | AN Control   | |                     | | NAS Control  | |
   | | Application  | |                     | | Application  | |
   | +--------------+ |                     | +--------------+ |
   | +--------------+ |                     | +--------------+ |
   | | Access Node  | |   ANCP Messages     | | Access Node  | |
   | | Control      |<----------------------->| Control      | |
   | | Protocol     | |                     | | Protocol     | |
   | | (AN side)    | |                     | | (NAS side)   | |
   | +--------------+ |                     | +--------------+ |
   +------------------+                     +------------------+

Figure 1: Architectural Context For the Access Node Control Protocol

<end proposed text>

If everyone accepts this text, we have come a long way toward resolution 
of our issues. The implication is that it is up to the Broadband Forum 
to specify the control applications (e.g., by updating TR-147).

The point of view above will require me to add text at various points in 
the document to reflect necessary communication between the protocol 
level and the control applications. For example, there should be a 
signal to the control applications when an adjacency has been established.

Here are the consequences for the specification of the DSL Topology 
Discovery capability. Cross-references use the section numbers as they 
are in the current version (-12) of the draft.
_______________________________________

Proposal for Section 5.2.1, Goals

Replace the entire sub-section with the following introductory sentence:

"Section 3.1 of RFC 5851 describes the requirements for the DSL Topology 
Discovery capability."

_______________________________________

Proposal for Section 5.2.2, Message Flow

Replace with the following text.

<begin replacement text>

5.2.1 Control Context

The AN control application in the DSLAM requests ANCP to send a 
DSL-specific Port Up message to the NAS under the following circumstances:
  - when a new adjacency with the NAS is established, for each DSL
    loop that is synchronized at that time;
  - subsequent to that, whenever a DSL loop resynchronizes; and
  - whenever the AN control application wishes to signal that a
    line attribute has changed.

The AN control application in the DSLAM requests ANCP to send a 
DSL-specific Port Down message to the NAS under the following circumstances:
  - when a new adjacency with the NAS is established, for each DSL
    loop that is provisioned but not synchronized at that time; and
  - subsequent to that, whenever a DSL loop loses synchronization.

The AN control application passes information to identify the DSL loop 
to ANCP to include in the Port Up or Port Down message, along with 
information relating to DSL loop attributes.

In the case of bonded copper loops to the customer premise (as per DSL 
multi-pair bonding described by [G.988.1] and [G.988.2]), the AN control 
application requests that ANCP send DSL-specific Port Up and Port Down 
messages for the aggregate "DSL bonded circuit" (represented as a single 
logical port) as well as the individual DSL loops of which it is 
comprised. The information relating to DSL line attributes that is 
passed by the AN control application is aggregate information

ANCP generates the DSL-specific Port Up or Port Down message and 
transfers it to the NAS. ANCP on the NAS side passes an indication to 
the NAS control application that a DSL Port Up or Port Down message has 
been received along with the information contained in the message.

The NAS control application updates its view of the DSL loop state, 
performs any required accounting operations, and uses any included line 
attributes to adjust the operation of its queueing/scheduling mechanisms 
as they apply to data passing to and from that DSL loop.

Figure x shows typical messaging sequences.

    1.  NAS ------------------------ Access -----  Home ----- Subscriber
                                      Node        Gateway

             <----- Port Up                 <----- DSL
                  (default line parameters)       Signal

    2.  NAS ------------------------ Access -----  Home ----- Subscriber
                                      Node        Gateway

             <----- Port Up                 <----- DSL
                   (updated line parameters)     Resynch

    3.  NAS ------------------------ Access -----  Home ----- Subscriber
                                      Node        Gateway

            <--- Port Down                  <---- DSL
                                               Loss of Signal

           Figure x: ANCP Message Flow For DSL Topology Discovery

<end replacement text>

_______________________________________

Proposal for sub-section 5.2.3.1, Protocol Requirements

Replace with the following text.

<begin replacement text>

5.2.2.1. Protocol Requirements

    The DSL topology discovery capability is assigned capability type
    0x01.  No capability data is associated with this capability.

5.2.2.1.1. Protocol Requirements At the Access Node

The AN-side implementation of ANCP MUST be able to create DSL-specific 
Port Up and Port Down messages according to the format specified in 
[old] Section 5.2.3.2.

The AN-side implementation of ANCP MUST be able to accept any 
information passed to it by the AN control application that may validly 
be included in any of the TLVs specified in [old] Section 5.2.3.3, 
package that information as TLVs, and include these TLVs within the Port 
Up or Port Down message.

The AN-side implementation of ANCP MUST follow the AN-side procedures 
associated with DSL-specific Port Up and Port Down messages as they are 
specified in [old] Section 5.2.3.2.1.

5.2.2.1.2. Protocol Requirements At the Network Access Server

The NAS-side implementation of ANCP MUST be able to receive and validate 
DSL-specific Port Up and Port Down messages according to the format 
specified in [old] Section 5.2.3.2.

The NAS-side implementation of ANCP MUST follow the NAS-side procedures 
associated with DSL-specific Port Up and Port Down messages as they are 
specified in [old] Section 5.2.3.2.1.

The NAS-side implementation of ANCP MUST be able to extract the 
information contained in any of the TLVs specified in [old] Section 
5.2.3.3 and make that information available to the NAS control application.

<end replacement text>

_______________________________________

Proposal for sub-section 5.2.3.2, ANCP Port UP and Port DOWN Event 
Message Descriptions

Leave this unchanged except for the following two corrections based on 
list comments:

-- fix Figure 8 to refer to Section 4.6 rather than 4.4
-- change the "Block Length" field in Figure 8 to "Reserved", and drop 
the mention of that field in the text below the figure.

_______________________________________

Proposal for sub-section 5.2.3.2.1, Procedures

Completely rewrite the section as follows. Sub-section numbering will 
change, so I'll designate the new sub-sub-sections as SS1 and SS2 here 
pending the new numbering.

<begin replacement text>

SS1 Procedures At the Access Node

The AN-side implementation of ANCP MUST create and transmit a 
DSL-specific Port Up or Port Down message when requested by the AN 
control application and presented with the information needed to build a 
valid message, except if transmission is inhibited by a rate-dampening 
mechanism. It is RECOMMENDED that the Access Node use a dampening 
mechanism per DSL loop to control the rate at which state changes are 
communicated to the NAS.

At the top level, the extension block within a DSL-specific Port Up or 
Port Down message MUST include the Access-Loop-Circuit-ID TLV to 
identify the DSL loop and MAY include the Access-Loop-Remote-Id, 
Access-Aggregation-Circuit-ID-Binary, and/or 
Access-Aggregation-Circuit-ID-ASCII TLVs if the associated information 
has been passed from the AN control application.

TLVs presenting DSL line attributes (i.e., the TLVs specified in [old] 
Section 5.2.3.3.6) MUST be encapsulated within the DSL-Line-Attributes 
TLV. In the Port Up message, TLVs presenting one or more DSL line 
attributes MUST be present, and hence the DSL-Line-Attributes TLV 
encapsulating them MUST be present at the top level within the extension 
block. In the Port Down message, TLVs presenting DSL line attributes and 
hence the DSL-Line-Attributes TLV encapsulating them MAY be present.

If the AN-side implementation receives a Generic Response message 
indicating an error in a Port Up or Port Down message that it has sent, 
it MUST either take appropriate action at the protocol level or indicate 
the nature of the error and relevant diagnostic information to the AN 
control application, as specified for the Result Code value received in 
the Generic Response. [This last bit is based on proposals in response 
to Matthew Bocci's review, presented at the IETF 79 meeting. These 
proposals will be presented separately to the list once we have this 
issue ironed out.]

SS2 Procedures At the Network Access Server

The NAS-side implementation of ANCP MUST be prepared to receive Port Up 
and Port Down messages for a given DSL loop or logical port at any time 
after negotiation of an adjacency has been completed. It is possible for 
two Port Up messages in succession to be received for the same DSL loop 
without an intervening Port Down message, and vice versa.

The NAS-side implementation SHOULD validate each message against the 
specifications given in [old] Section 5.2.3.2 and in the TLV 
specifications given in [old] Section 5.2.3.3. If it finds an error it 
MAY generate a Generic Response message containing an appropriate Result 
Code value and a Status-Info TLV with further information. The 
Status-Info TLV MUST contain a copy of the Access-Loop-Circuit-ID TLV as 
its first encapsulated TLV if that TLV was present in the original Port 
Up or Port Down message. The Status-Info TLV MUST contain other 
information as described below or in Section 4.6. [This reference to 
Section 4.6 assumes that my proposals for additional text for Code 
descriptions are accepted.]

Possible errors at the general message level are:

  - 4  One or more of the specified ports do not exist
       This is possible if the NAS has or has obtained from AAA
       an initial record of provisioned DSL loops.

  - 7  Invalid Partition ID

  - 81 Request message type not implemented
       This is only possible if there is a capability mismatch between
       the NAS and the AN.

  - 82 Transaction identifier out of sequence

  - 83 Malformed message
       Aside from more general formatting errors, this Code value is
       applicable if the Message Type in the extension block header
       does not match the Message Type in the general ANCP header or
       if the Tech Type field does not have a recognizable value.

Possible errors at the TLV level are:

  - 84 Mandatory TLV missing
       This indicates that the Access-Loop-Circuit-ID TLV or,
       in the case of a Port Up message, the DSL-Line-Attributes
       TLV is not present. The Status-Info TLV within the
       Generic Response message MUST contain an instance of each
       missing TLV with the length set to zero and the value
       field empty.

  - 85 Invalid TLV contents
       A TLV specified in [old] Section 5.2.3.3 is present in the
       message, but the contents of the field do not conform to
       the specifications of that section. This Code value MUST
       also be used to indicate that the DSL-Line-Attributes TLV
       is present but empty in a Port Up message. The Status-Info
       TLV within the Generic Response message MUST contain a copy
       of the invalid TLV with its contents as received. If the
       erroneous TLV is the Access-Loop-Circuit-ID TLV, it is still
       necessary to place a copy of that TLV into the Status-Info
       TLV, even though one copy is already present as required by
       the text in this section preceding the list of individual
       Code values.

If the received message passes validation, the NAS-side implementation 
of ANCP MUST extract the information from the TLVs contained in the 
message and present that information along with an indication of the 
message type to the NAS control application. If validation of individual 
TLVs fails but the message as a whole can be processed, the NAS-side 
implementation of ANCP MAY pass the valid message contents to the NAS 
control application.

When extracting information from TLVs whose values are characterized as 
ASCII strings, the NAS MUST NOT assume that these strings are 
zero-terminated.

<end replacement text>

_______________________________________

Proposal for Section 5.2.3.3, TLVs For DSL Topology Discovery

General: remove any text indicating that a given TLV is optional or 
mandatory.

---

From: <[email-masked]>
Date: Mon, 29 Nov 2010 12:02:47 +0100

Tom, all,

pls. see my comments inline:

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Tom Taylor
Gesendet: Samstag, 27. November 2010 22:20
An: [email-masked]
Betreff: [ANCP] New proposal to clarify our discussion

<begin proposed text>

2. Introduction

<end proposed text>

<begin replacement text>

5.2.1 Control Context

>T.H:Idle state is missing; Needs to be aligned with protocol version 12.
     See also Framework rfc5851 chapter 3.1. See also chapter 5.2.3.2.1 and 5.2.3.3.6.16 of protocol draft v12; 
     additional text needed:
>Proposal: 
> -	Whenever a DSL loop is equipped in an AN but administrative disabled is signalled as "IDLE".

            <--- Port Down                  <---- DSL
                                               Loss of Signal

<end replacement text>

> T.H.: Figure needs to be aligned to framework; means CPE left side, NAS right side.

<begin replacement text>

<end replacement text>

<begin replacement text>

>T.H.: In 5.2.3.3.5 of prptocol draft version 12 is written: " When the DSL-Line-Attributes TLV is present in a Port DOWN message it SHOULD NOT include any TLVs other than DSL-Type and DSL-Line-State". How does it correlate to  "DSL-Line-Attributes TLV encapsulating them MAY be present"? Is the meaning the same?

  - 7  Invalid Partition ID

  - 83 Malformed message

<end replacement text>

General: remove any text indicating that a given TLV is optional or 
mandatory.
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Tom Taylor <[email-masked]>
Date: Tue, 30 Nov 2010 08:59:47 -0500

Thank you very much for your implied general acceptance of the proposal. 
I've snipped everything but your comments and immediate context and 
responded to them.

> Betreff: [ANCP] New proposal to clarify our discussion
...
>> -	Whenever a DSL loop is equipped in an AN but administrative disabled is signalled as "IDLE".
[PTT] I knew I was being imprecise here. I'm glad to be corrected.

...
>               <----- Port Up<----- DSL
>               <----- Port Up<----- DSL
>              <--- Port Down<---- DSL

[PTT] Yes, that seems more natural to me, too.
...
>> T.H.: In 5.2.3.3.5 of prptocol draft version 12 is written: " When the
  DSL-Line-Attributes TLV is present in a Port DOWN message it SHOULD NOT
include any TLVs other than DSL-Type and DSL-Line-State". How does it
  correlate to  "DSL-Line-Attributes TLV encapsulating them MAY be present"?
  Is the meaning the same?

[PTT] The two statements are consistent, but definitely not the same. Is 
it acceptable to suggest that the statement about which TLVs may be 
present is an application-level statement?
...

---

From: <[email-masked]>
Date: Wed, 1 Dec 2010 08:54:00 +0100

Hi Tom,

o.k. I'm fine with the modifications.

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Tom Taylor
Gesendet: Dienstag, 30. November 2010 15:00
An: Haag, Thomas
Cc: [email-masked]
Betreff: Re: [ANCP] New proposal to clarify our discussion

...

...

...