Subject: [ANCP] ANCP base protocol issues: normative text for DSL Topology Discovery

From: Tom Taylor <[email-masked]>
Date: Thu, 18 Nov 2010 18:13:32 -0500

This is a fairly big issue. We had discussion before the meeting, and my 
charts at the meeting had a number of proposals. We determined at the 
meeting that there wasn't a clear normative specification of what the 
NAS should do with Port Up/Down (in particular) from the AN. Aside from 
all that, Matthew Bocci's review indicated that some of the text in the 
DSL capabilities sections should be replaced by references to the 
framework document.

I've pondered for a few days how to present text proposals to the list, 
and decided to do a section by section proposal for each DSL capability 
in turn. This message deals with the DSL Topology Discovery use case, 
section 5.2.

_______________________________________

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

Delete this sub-section. There is normative text in the procedures 
section that provides the same information.

_______________________________________

Proposal for sub-section 5.2.3.1, Protocol Requirements

Leave this unchanged.

_______________________________________

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

To provide expected service levels, the NAS needs to learn the initial 
attributes of the DSL line before the subscriber can log in and access 
the services provisioned for the subscription.  When the attributes 
change, the NAS needs to learn the new values. Hence the AN MUST 
generate and transmit an ANCP Port Up Event message to the NAS in the 
following cases:

    Case 1: when an adjacency is established or reestablished, if
    the DSL line is already up at that time;

    Case 2: when a DSL line initially comes up subsequent to the
    establishment of an adjacency.

The AN SHOULD generate and transmit an ANCP Port Up Event message to the 
NAS in the following cases:

    Case 3: when a line comes up again after signal was lost on the
    line;

    Case 4: when a line attribute changes, and in particular when the
    line resynchronizes to a different rate.

Upon loss of signal on the DSL line, the Access Node SHOULD generate an 
ANCP Port Down message and send it to the NAS.

It is RECOMMENDED that the Access Node uses a dampening mechanism per 
DSL line to control the rate at which state changes are communicated to 
the NAS.

Every Port Up and Port Down message MUST contain the following TLVs:

  - Access-Loop-Circuit-ID;
  - Access-Loop-Remote-Id, if this is configured at the AN for
    the access line concerned;
  - Access-Aggregation-Circuit-ID-Binary, if this is configured
    at the AN for the access line concerned;
  - Access-Aggregation-Circuit-ID-ASCII, if this is configured
    at the AN for the access line concerned;
  - DSL-Line-Attributes.

In the Port Up message, the DSL-Line-Attributes TLV MUST contain the 
following encapsulated TLVs in all cases:

  - Actual-Net-Data-Rate-Upstream;
  - Actual-Net-Data-Rate-Downstream;
  - Actual-Interleaving-Delay-Upstream;
  - Actual-Interleaving-Delay-Downstream.

The DSL-Line-Attributes TLV contains additional line attributes 
according to the case:

  - in Cases 1 and 2, the DSL-Line-Attributes TLV MAY contain the 
DSL-Line-State TLV and MUST contain the DSL-Type TLV, the 
Access-Loop-Encapsulation TLV, and all of the other line attribute TLVs 
described in Section 5.2.3.3.6 for which values have been configured for 
this access line on the AN.

  - in Case 3, the DSL-Line-Attributes TLV MAY contain the 
DSL-Line-State TLV and SHOULD contain the DSL-Type TLV, the 
Access-Loop-Encapsulation TLV, and all of the other line attribute TLVs 
described in Section 5.2.3.3.6 for which values have been configured for 
this access line on the AN.

  - in Case 4, the DSL-Line-Attributes TLV MUST contain the TLV(s) 
corresponding to the attribute(s) whose value has changed.

The DSL-Line-Attributes TLV in a Port Down message MUST contain the 
DSL-Line-State TLV, but SHOULD NOT include any other line attribute 
except as described below.

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 MUST 
report the aggregate net data rate and other attributes for the "DSL 
bonded circuit" (represented as a single logical port) to the NAS in a 
Port Up message.  Any change in the aggregate net data rate of the "DSL 
bonded circuit" (due to a change in net data rate of individual 
constituent DSL lines or due to change in state of the individual 
constituent DSL lines) MUST be reported by the AN to the NAS in a Port 
Up message.  The DSLAM MUST also report the "aggregate" state of the 
"DSL bonded circuit" to the NAS via Port Up and Port Down messages.

If at any time the Access Node receives a Generic Response for a given 
DSL access line with a Result Code value of 256 "Line attributes 
required", it MUST generate either a Port Up or Port Down message for 
the indicated access line, according to the current line state. The 
message MUST include all of the TLVs that would be present for a Port Up 
message in Case 1 or 2. In addition, if the line is currently down, the 
DSL-Line-State TLV MUST be included in the DSL-Line-Attributes TLV as it 
is for all other Port Down messages.

SS2 Procedures at the NAS

The NAS MUST be prepared to receive a Port Up or Port Down message for a 
given access line at any time. It is possible for two Port Up or two 
Port Down messages to arrive in succession because intervening changes 
of state were filtered out at the Access Node.

In either a Port Up or Port Down message with Tech Type = 0x05 (DSL), 
the Access-Loop-Circuit-ID and DSL-Line-Attributes TLVs MUST always be 
present. The Access-Loop-Remote-Id, 
Access-Aggregation-Circuit-ID-Binary, and/or 
Access-Aggregation-Circuit-ID-ASCII TLVs MAY be present. If they are, 
the NAS MUST retain a record of their values for use in messages sent to 
the Access Node.

The DSL-Line-Attributes TLV in a Port Up message with Tech Type = 0x05 
MUST always contain the Actual-Net-Data-Rate-Upstream, 
Actual-Net-Data-Rate-Downstream, Actual-Interleaving-Delay-Upstream, and 
Actual-Interleaving-Delay-Downstream TLVs. It MAY contain additional 
TLVs. The first Port Up message received for a given access line after 
an adjacency has been established or reestablished MUST contain these 
additional TLVs, including in particular the DSL-Type and 
Access-Loop-Encapsulation TLVs. If it does not, the NAS SHOULD generate 
a Generic Response message containing a Result value of Failure (0x4) 
and a Code value of 256 "Line attributes required". The Status-Info TLV 
within the Generic Response MUST indicate the message type (Port Up, 
0x80) and MAY contain an error message. It MUST NOT contain any TLVs.

The DSL-Line-Attributes TLV in a Port Down message with Tech Type = 0x05 
MUST always contain the the DSL-Line-State TLV. If other line attributes 
are present, the NAS MAY process them or MAY silently ignore them.

If a mandatory TLV according to the above description is missing, the 
NAS SHOULD log the error and MAY generate a Generic Response message 
with Result equal to Failure and Code value equal to 84 "Mandatory TLV 
missing". The Status-Info TLV within the Generic Response MUST indicate 
the message type (Port Up, 80, or Port Down, 81) and MAY contain an 
error message. It MUST contain instances of the missing TLVs, with the 
Length field in each set to zero and the Value field empty.

<end replacement text>

The advice dealing with Code 84 is generic. I propose to put it in the 
definition of the Code value, in section 4.6.
_______________________________________

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, 22 Nov 2010 15:38:50 +0100

Tom,

attached comments and views on proposed changes. 
Please notify, that changes and remarks are marked in ">>>":

regards
Thomas

...

>>>Remark: Should be kept because message flow is key element and should
be consistent also to figure 11 of use case "line configuration".

...

	To provide expected service levels, the NAS needs to learn the
initial 
	attributes of the DSL line before the subscriber can log in and
access 
	the services provisioned for the subscription.  When the
attributes 
>>>	change, the NAS needs to learn the new values >>>immediately<<<.
Hence the AN MUST 
	generate and transmit an ANCP Port Up Event message to the NAS
in the 
	following cases:

	    Case 1: when an adjacency is established or  e-established,
if the DSL line is already up at that time;

>>>	The AN >>>must<<< generate and transmit an ANCP Port Up Event
message to the 

    	Case 4: when a line attribute changes, and in particular when
the
    	line resynchronizes to a different rate.

>>>	Upon loss of signal on the DSL line, the Access Node >>>must<<<
generate an 

>>>	When an adjacency is established or re-established, a port down
message must be send if the DSL line is down or idle at that time.<<<

	It is RECOMMENDED that the Access Node uses a dampening
mechanism per 
	DSL line to control the rate at which state changes are
communicated to 
	the NAS.

	Every Port Up and Port Down message MUST contain the following
TLVs:

	In the Port Up message, the DSL-Line-Attributes TLV MUST contain
the 
	following encapsulated TLVs in all cases:

>>>  	- Maximum achievable/attainable net data rate (upstream)
>>>  	- Maximum achievable/attainable net data rate (downstream)
>>>  	- Minimum net data rate configured for the Access Loop
(upstream)
>>>  	- Minimum net data rate configured for the Access Loop
(downstream)
>>>  	- Maximum net data rate configured for the Access Loop
(upstream)
>>>  	- Maximum net data rate configured for the Access Loop
(downstream)
>>>  	- Minimum net data rate in low power state configured for the
Access
>>>      Loop (upstream)
>>>  	-Minimum net data rate in low power state configured for the
Access
      Loop (downstream)

>>>	Remark: As it was written before it seems misleading because
clear mandatory statement for all TLVs is missing. <<<

	according to the case:

>>>  	- in Cases 1 and 2, the DSL-Line-Attributes TLV >>>Must<<<
contain the 
	DSL-Line-State TLV and MUST contain the DSL-Type TLV, the 
	Access-Loop-Encapsulation TLV, and all of the other line
attribute TLVs 
	described in Section 5.2.3.3.6 for which values have been
configured for 
	this access line on the AN.

  	_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Tom Taylor <[email-masked]>
Date: Mon, 22 Nov 2010 13:49:52 -0500

You're the operator, so you know what you need, but I'll summarize. 
Basically you are saying that you need all those TLVs in every Port Up 
message, even though (if I understand correctly) most of them will 
rarely change. Is that really your requirement?

On 22/11/2010 9:38 AM, [email-masked] wrote:
>>>> 	change, the NAS needs to learn the new values>>>immediately<<<.
> Hence the AN MUST
>>>> 	The AN>>>must<<<  generate and transmit an ANCP Port Up Event
> message to the
>>>> 	Upon loss of signal on the DSL line, the Access Node>>>must<<<
> generate an
> clear mandatory statement for all TLVs is missing.<<<
>
>>>>   	- in Cases 1 and 2, the DSL-Line-Attributes TLV>>>Must<<<
> contain the

---

From: Tom Taylor <[email-masked]>
Date: Mon, 22 Nov 2010 18:58:31 -0500

Below.

...

The original SHOULDs were there to allow for message filtering in the 
case where too many messages might otherwise be generated. Are you 
against the flow control measures, or are you looking for text 
specifying the exact circumstances when one can deviate from MUST?

TomT

---

From: Tom Taylor <[email-masked]>
Date: Mon, 22 Nov 2010 19:01:45 -0500

Below.

...
> be consistent also to figure 11 of use case "line configuration".

I was going to go on and propose the same treatment for 'line 
configuration' and 'remote connectivity testing' (which is what it 
should be called according to the framework.

I'll ask: what does the section add that is not in the proposed 
normative text?

TomT

---

From: <[email-masked]>
Date: Thu, 25 Nov 2010 10:29:44 +0100

Tom,

please see our answers inline:

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Tom Taylor
Gesendet: Montag, 22. November 2010 19:50
An: Haag, Thomas
Cc: [email-masked]
Betreff: Re: [ANCP] ANCP base protocol issues: normative text for DSL TopologyDiscovery

>>TH: Yes, Port up message contain all paramters to be sent by access node. 
      This is basic feature since first ANCP implementations. 
      All known AN implementations support this.
      This goes inline with Manuel's statement last meeting.

---

From: <[email-masked]>
Date: Thu, 25 Nov 2010 11:07:23 +0100

Tom,

my answer is as follows:

TH: I'm looking to define the exact circumstances. If you stay for "Should" e.g. AN - BNG pairs may exchange port status messages after adjacency comes up again, other AN - BNG pairs may not. This leads in multi vendor environments to different implementations according different interpretation of that cases. This must be excluded by standard. Therefore we propose to go for "MUST".

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Tom Taylor
Gesendet: Dienstag, 23. November 2010 00:59
An: Haag, Thomas
Cc: [email-masked]
Betreff: Re: [ANCP] ANCP base protocol issues: normative text for DSL TopologyDiscovery

Below.

...

TomT

---

From: <[email-masked]>
Date: Thu, 25 Nov 2010 11:12:25 +0100

Tom,

our answer is as follows:

Basically I agree on that we have redundant text here. But the key point is to keep the diagrams in the text because the diagram guide the reader.
A diagram shows at a glance which elements are involved and which message is communicated from which element to which endpoint.   

regards
Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Tom Taylor
Gesendet: Dienstag, 23. November 2010 01:02
An: Haag, Thomas
Cc: [email-masked]
Betreff: Re: [ANCP] ANCP base protocol issues: normative text for DSL TopologyDiscovery

Below.

...

TomT

---

From: Tom Taylor <[email-masked]>
Date: Thu, 25 Nov 2010 08:18:49 -0500

Thank you very much for your responses on this point and the others. In 
the absence of other comment I believe that allows me to resolve this 
particular issue. I'll post amended text for review, then post text 
based on similar principles for the other two DSL capabilities.

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 25 Nov 2010 15:47:16 +0100

Hello Tom,

A comment or two, inline...

>From a protocol perspective, the last three above are thus optional.

>   - DSL-Line-Attributes.

Is this mandatory? I know we have the fabled tech-types, but a port-up/down
is not necessarily only a triggered by a DSL line, and Port-up/down is a
generic message. Hence it would appear that port-up messages with DSL tech
type MUST/SHOULD contain some DSL attributes. Port-UP messages without
dsl-tech type would not need to contain these attributes.

In addition, is there a reason to have dsl-line attributes signalled in a
port down?

Thanks,
Woj.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 25 Nov 2010 11:34:58 -0500

Hi. Responses below.

On 25/11/2010 9:47 AM, Wojciech Dec wrote:
> On 19/11/2010 00:13, "Tom Taylor"<[email-masked]>  wrote:
>

[PTT] At the NAS end, these MAY be present in the message. At the AN 
end, they MUST be added to the message if they are configured. Is this OK?
> In addition, is there a reason to have dsl-line attributes signalled in a

[PTT] The requirement has always been there, in the form of the 
mandatory presence of the DSL-Line-State TLV within the 
DSL-Line-Attributes TLV in the Port Down message.

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 25 Nov 2010 17:50:12 +0100

On 25/11/2010 17:34, "Tom Taylor" <[email-masked]> wrote:

> I understand but for a protocol document, the MUST is normative for the
> protocol and since the TLV is clearly optional, and the recipient has no idea
> whether the AN has or has not been configured in some way, it does appear to
> be rather odd.
> You can likely have a requirement somewhere else in the doc which states that
> the AN must send optional attributes when configured to do so... If that
> helps. 
> 
>> >
>>> >>    - DSL-Line-Attributes.
>> >
> Ok, but... Why? There seems to be no reason...
> 
> Regards,
> Woj.
> 
> 
>> >
>> > Thanks,
>> > Woj.
>> >
>> >
>> >

---

From: Tom Taylor <[email-masked]>
Date: Thu, 25 Nov 2010 14:34:54 -0500

I had to think about this a lot, because I find it confusing. I think 
you are saying that the protocol provides a container for certain 
information, but whether that information is actually put into the 
container is out of scope of the document. I suspect that as a general 
statement this won't be acceptable to others on this list, but we can see.

On 25/11/2010 11:50 AM, Wojciech Dec wrote:
>
>
>
> On 25/11/2010 17:34, "Tom Taylor"<[email-masked]>  wrote:
>
>> Hi. Responses below.
>>
...

---

From: Tom Taylor <[email-masked]>
Date: Thu, 25 Nov 2010 14:46:35 -0500

I've had another thought. The problem is that in my mind the attributes 
concerned are not optional, but conditionally mandatory. Unfortunately 
RFC 2119 does not define "CONDITIONALLY MANDATORY", meaning that I am 
forced to use the construct "MUST ... if ...".

So the questions are:

1) Do you agree that the attributes are conditionally mandatory?

2) If so, how do we express that?

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 26 Nov 2010 10:09:57 +0100

Hello Tom,

On 25/11/2010 20:46, "Tom Taylor" <[email-masked]> wrote:

> 1. Do you agree that the attributes are conditionally mandatory?

Woj> On a protocol level, I don¹t think that one can even talk of
conditionally mandatory unless the recipient of the message has a way to
check whether the condition holds at the sender.
> Woj> I would say that ANCP is not unique here in having attributes/TLVs that
> are optionally sent. At a protocol requirement level for me these are MAYs,
> and some protocols prefer to denote that using values like ³0+²
> As a functional requirement of the device, based on what has been said, we
> want a requirement of the type ³The device MUST be configurable to send the
> following attributes....² Logic being that if such configuration is not
> present, and the attributes do not get sent and this does not result in a
> protocol error.
> 
> Regards,
> Woj.
>

---

From: "DE CNODDER, STEFAAN (STEFAAN)" <[email-masked]>
Date: Fri, 26 Nov 2010 11:15:08 +0100

>From protocol perspective, most attributes look to me optional (but not for sure Access-Loop-Circuit-ID), but of course, other specifications may rely on these optional TLVs and can be mandatory for that other spec to work, and if an implementation is compliant with that other spec, then that implementation will also sends these attributes.  So which TLVs are sent by an AN depends on to which spec the AN is compliant to.  It is at a minimum compliant to the protocol draft.  On top of that it can be compliant to other documents (e.g., written by BBF).  I do not see the need to make it configurable, the AN just have to sent all TLVs it supports.

I am also ok with making all TLVs mandatory, but a spec describing many mandatory TLVs without explaining how the NAS is supposed to process them, looks strange to me.  And if a TLV is missing then the NAS might reject the message because message not compliant to the spec, although the TLV is maybe not used in the spec.

Regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: donderdag 25 november 2010 20:35
To: Wojciech Dec
Cc: [email-masked]
Subject: Re: [ANCP] ANCP base protocol issues: normative text for DSL Topology Discovery

...

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 26 Nov 2010 14:40:20 +0100

On 26/11/2010 11:15, "DE CNODDER, STEFAAN (STEFAAN)"
<[email-masked]> wrote:

> 
> From protocol perspective, most attributes look to me optional (but not for
> sure Access-Loop-Circuit-ID), but of course, other specifications may rely on
> these optional TLVs and can be mandatory for that other spec to work, and if
> an implementation is compliant with that other spec, then that implementation
> will also sends these attributes.  So which TLVs are sent by an AN depends on

Sorry, what other standard spec?

> to which spec the AN is compliant to.  It is at a minimum compliant to the
> protocol draft.  On top of that it can be compliant to other documents (e.g.,
> written by BBF).  I do not see the need to make it configurable, the AN just
> have to sent all TLVs it supports.

That's an implementation decision. Protocol wise, sending redundant stuff is
not required, and when such stuff is not there it is not an error.

> 
> I am also ok with making all TLVs mandatory, but a spec describing many
> mandatory TLVs without explaining how the NAS is supposed to process them,
> looks strange to me.  And if a TLV is missing then the NAS might reject the
> message because message not compliant to the spec, although the TLV is maybe
> not used in the spec.

If a mandatory TLV is missing, a NAS or AN must reject the message. If a TLV
that is not in the spec is missing, but expected, you'd be in proprietary
territory.

Regards,
Woj.

---

From: Tom Taylor <[email-masked]>
Date: Fri, 26 Nov 2010 08:56:18 -0500

OK, the issue seems to be where one draws the line between the protocol 
and the application. I seem to see two extreme positions:

a. Everything is optional except maybe the Access-Loop-Circuit-ID.

b. Everything is mandatory, and we have to describe the use of every TLV 
at the NAS.

I'm appealing to the Chairs to give me some direction at this point, 
because I can't pin down a consensus position.

On 26/11/2010 5:15 AM, DE CNODDER, STEFAAN (STEFAAN) wrote:
>
>> From protocol perspective, most attributes look to me optional (but
>> not for sure Access-Loop-Circuit-ID), but of course, other
>> specifications may rely on these optional TLVs and can be mandatory
>> for that other spec to work, and if an implementation is compliant
>> with that other spec, then that implementation will also sends
>> these attributes.  So which TLVs are sent by an AN depends on to
>> which spec the AN is compliant to.  It is at a minimum compliant to
>> the protocol draft.  On top of that it can be compliant to other
>> documents (e.g., written by BBF).  I do not see the need to make it
>> configurable, the AN just have to sent all TLVs it supports.
>
> I am also ok with making all TLVs mandatory, but a spec describing
> many mandatory TLVs without explaining how the NAS is supposed to
> process them, looks strange to me.  And if a TLV is missing then the
> NAS might reject the message because message not compliant to the
> spec, although the TLV is maybe not used in the spec.
>
> Regards, Stefaan
>
...

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 26 Nov 2010 15:19:34 +0100

Hello Tom,

The opinions expressed are not as extreme as you see them to be.

A summary:
* There are attributes, which if not present in a given message, indicate a
fatal error. These are mandatory.
* There are attributes, which can be sent if implemented/configured. Not
seeing these in messages at the recipient end is not an error. Seeing these
in messages is also not an error.
* There are attributes, which in the current spec are said to be required
(mandatory) for no apparent reason (eg sending line-rate info in Port-down
messages). 

In terms of a ³configuration to send², one can see it as an ³implementation
to send², ie optional attributes are to be sent if implemented or must be
sent if configured.

Thanks,
Woj.

---

From: <[email-masked]>
Date: Fri, 26 Nov 2010 16:00:56 +0100

All,
 
it seems to me that we are discussing about options which may exist
hypothetically.
If a DSL port works according standard ITU-T G. 997.1 DSL provides the
parameter set we are alking about.
 
Are any doubts on that? I don't think so.
 
If a DSL port is working according standard ITU-T G.997.1 it provides
listed parameterset. 
 
If ANCP supports standard behaviour the TLV's "MUST" be defined in a
protocol spec and also listed. 
 
ANCP must enable the usage of them. So appropriate TLVs must be defined
as a "MUST" because an AN has to support it.
 
Therefore it is the wrong  way to classify in optional and mandatory.
All TLVs are mandatory because ITU-T does not make a difference here.
 
So I recommend for consistency reasons to follow standards to define
TLVs and not distinguish between optional how to use them. 
 
Regards
Thomas

Parameterset G.997.1 
1

DSL Type: ADSL Transmission System

This parameter defines the transmission system in use (e.g. ADSL, ADSL2,
ADSL2plus, SDSL, VDSL2)

ITU-T G.997.1 

Section 7.5.1.1

2

DSL Port State

Port up (showtime L0) / Port down (not synchronized, L3) / Power Down
(L2)

ITU-T G.997.1 Section 7.5.1.5

3

Actual data rate Up- and Downstream

Actual net data rate upstream and downstream of a synchronized DSL port

ITU-T G.997.1

Section 7.5.2.1

4

Attainable Data Rate Up- and Downstream

Maximum net data rate which can be achieved

ITU-T G.997.1 Section 7.5.1.20 and 7.5.1.19

5

Minimum Data Rate

minimum net data rate desired by the operator in kbit/s

ITU-T G.997.1 

Section 7.3.2.1.1

6

Maximum Data Rate

maximum net data rate desired by the operator in kbit/s

ITU-T G.997.1

Section 7.3.2.1.3

7

Minimum Data Rate in low power state

minimum net data rate desired by the operator during the low power state
(L1/L2)

ITU-T G.997.1

Section 7.3.2.1.5

8

Maximum Interleaving Delay

maximum one-way interleaving delay, coded in ms (2 - 63) or with special
value (no boundaries, fast channel)

ITU-T G.997.1

Section 7.3.2.2

9

Actual interleaving Delay

Value in milliseconds which corresponds to inter leaver setting.

ITU-T G.997.1

section 7.5.2.3

________________________________

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Wojciech Dec
Gesendet: Freitag, 26. November 2010 15:20
An: Tom Taylor; BOCCI Matthew
Cc: [email-masked]; DE CNODDER,STEFAAN (STEFAAN)
Betreff: Re: [ANCP] ANCP base protocol issues: normative text for DSL
Topology Discovery

Hello Tom,

A summary:

*	There are attributes, which if not present in a given message,
indicate a fatal error. These are mandatory. 
*	There are attributes, which can be sent if
implemented/configured. Not seeing these in messages at the recipient
end is not an error. Seeing these in messages is also not an error. 
*	There are attributes, which in the current spec are said to be
required (mandatory) for no apparent reason (eg sending line-rate info
in Port-down messages). 

In terms of a "configuration to send", one can see it as an
"implementation to send", ie optional attributes are to be sent if
implemented or must be sent if configured.

Thanks,
Woj.

	OK, the issue seems to be where one draws the line between the
protocol
	and the application. I seem to see two extreme positions:
	
	a. Everything is optional except maybe the
Access-Loop-Circuit-ID.
	
	b. Everything is mandatory, and we have to describe the use of
every TLV
	at the NAS.
	
	I'm appealing to the Chairs to give me some direction at this
point,
	because I can't pin down a consensus position.
	
	...

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 26 Nov 2010 17:01:55 +0100

Thomas,

I do not think that anyone is claiming that for a dsl-tech-type, with dsl
line info, the parameters you indicate are not to be there, ie those are not
in doubt, and certainly are to be defined.
What is being discussed is whether other attributes (eg binary line-id, etc)
as well as having the port-up/down messages send all parameters in all
cases. It¹s rather reasonable that a port-up does not need to contain  a
dsl-tech type if it does not relate to a dsl line.

Regards,
Woj.

On 26/11/2010 16:00, "[email-masked]" <[email-masked]> wrote:

> If a DSL port is working according standard ITU-T G.997.1 it provides listed
> parameterset. 
>  
> If ANCP supports standard behaviour the TLV's "MUST" be defined in a protocol
> spec and also listed.
>  
> ANCP must enable the usage of them. So appropriate TLVs must be defined as a
> "MUST" because an AN has to support it.
>  
> Therefore it is the wrong  way to classify in optional and mandatory. All TLVs
> are mandatory because ITU-T does not make a difference here.
>  
> So I recommend for consistency reasons to follow standards to define TLVs and
> not distinguish between optional how to use them.
>  
> Regards
> Thomas
>  
> Parameterset G.997.1
>   1  DSL Type: ADSL Transmission  System  This parameter defines the
> transmission system  in use (e.g. ADSL, ADSL2, ADSL2plus, SDSL, VDSL2)  ITU-T
> G.997.1  Section  7.5.1.1
>   2  DSL Port  State  Port up (showtime L0) / Port down (not  synchronized,
> L3) / Power Down (L2)  ITU-T G.997.1 Section  7.5.1.5
>   3  Actual data rate Up- and  Downstream  Actual net data rate upstream and
> downstream  of a synchronized DSL port  ITU-T G.997.1 Section  7.5.2.1
>   4  Attainable Data Rate Up- and  Downstream  Maximum net data rate which can
> be  achieved  ITU-T G.997.1 Section  7.5.1.20 and 7.5.1.19
>   5  Minimum Data Rate  minimum net data rate desired by the operator  in
> kbit/s  ITU-T G.997.1  Section  7.3.2.1.1
>   6  Maximum Data Rate  maximum net data rate desired by the operator  in
> kbit/s  ITU-T G.997.1 Section  7.3.2.1.3
>   7  Minimum Data Rate in low power  state  minimum net data rate desired by
> the operator  during the low power state (L1/L2)  ITU-T G.997.1 Section
> 7.3.2.1.5 
>   8  Maximum Interleaving  Delay  maximum one-way interleaving delay, coded in
> ms (2  63) or with special value (no boundaries, fast  channel)  ITU-T
> G.997.1 Section  7.3.2.2
>   9  Actual interleaving  Delay  Value in milliseconds which corresponds to
> inter leaver setting.  ITU-T G.997.1 section  7.5.2.3
> 
> 
> In terms of a ³configuration to send², one can see it as an ³implementation to
> send², ie optional attributes are to be sent if implemented or must be sent if
> configured.
> 
> Thanks,
> Woj.
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 26 Nov 2010 13:42:14 -0500

The one qualification I would add to this is that the base protocol does 
not specify a Port Up except for the DSL case. GSMPv3 does.