Subject: RE: [L2CP] Draft charter for Layer 2 Control

From: "Kim Hyldgaard \(ST/LMD\)" <[email-masked]>
Date: Fri, 20 Jan 2006 07:44:13 +0100

Hi Sven,

Just a quick comment:

You have put the OAM and topology discovery in the description.
This is fine, however, I think you should remove Line Configuration
from the goals and milestones list and instead add a more general
track, like "Analyse additional use cases" and "Investigate a protocol
solution for additional use cases found in the analysis"

In this way we specify the two first use cases, topology discovery and
OAM, and make room for more use cases - whether it is line configuration
or multicast (or something else).

If this is too loose to put in the charter, I'd rather focus on topology
discovery and OAM only and get these two use cases in place together
with
the light weight transport and non-DSL technologies, and then consider
more use cases when re-chartering.

Br
Kim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 19. januar 2006 17:19
To: [email-masked]
Subject: [L2CP] Draft charter for Layer 2 Control

Dear L2CP'ers,

Here's a first stab at the charter for a new working group that would
focus on Layer 2 Control.

Some remarks:
- I've put initial focus on the *concept* of Layer 2 Control rather than
the *protocol* to achieve that concept. This is done in the spirit of
pitfall 5) described in draft-narten-successful-bof-00.txt
(Considerations for Having a Successful BOF). Having said that, I've
also put focus on GSMPv3 as the starting point for protocol work.
- I've assumed that the working group would fall under the umbrella of
the Internet Area.
- Positions for Chair(s), Technical Advisor(s) and Secretary(ies) are
left open
- Should we somehow refer to the l2cp work performed at the DSL Forum? I
assume we can only refer to publicly available documents. The only
document that has been made visible to the IETF is a previous version of
PD-021v2 (see email on the GSMP exploder, Nov 14, 2004)

Comments are welcome!

Regards,
Sven

Layer 2 Control (l2c)
=====================

Current Status: Non-existing Working Group

Chair(s):
TBD <tbd>
TBD <tbd>

Internet Area Director(s):
Mark Townsley <[email-masked]>
Margaret Wasserman <[email-masked]>

Internet Area Advisor:
Mark Townsley <[email-masked]>

Technical Advisor(s):
TBD <tbd>

Secretary(ies):
TBD <tbd>

Area Specific Mailing List:
[email-masked]

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: subscribe your_email_address
Archive: http://www.ietf.org/mail-archive/web/l2cp/index.html

Description of the charter for this WG:

When deploying value-added services across broadband access networks
(e.g. DSL), special care is required to obtain the desired level of
quality of service and effective service control. With the introduction
of so-called "triple play services" (i.e. high speed Internet access,
voice over IP and broadcast TV / Video on Demand), some means of
coordination between the different network elements in the access
network becomes necessary.

Traditionally, the different network elements are usually controlled by
separate element managers, which are connected to one set of network and
service management systems. Frequently, organizational boundaries will
be in place between departments operating the local loop, the
access/aggregation network and the IP network. One approach to obtain
the desired level of coordination would thus be based on the
introduction of standard business-to-business interfaces between these
domains. This approach may be a challenging one if real time behavior is
to be achieved.

The approach that will be considered by this working group consists of
the introduction of a dedicated control mechanism between an Access Node
(e.g. a DSLAM) and a Broadband Network Gateway (e.g. a BRAS). This
concept is called "Layer 2 Control" (l2c), in line with the ideas
discussed and being worked out by the DSL Forum (cf. PD-021v2 submitted
to the GSMP exploder on November 14, 2004).

Different applications can be identified where there is a desire for a
control plane between an Access Node and a BNG in order to perform
QoS-related, service-related and subscriber-related operations.

Firstly, this working group is responsible for writing the framework and
requirements for Layer 2 Control. This working group will consider the
input of the DSL Forum in the definition of the use cases.

Secondly, this working group will investigate a protocol solution to
achieve "Layer 2 Control" between an Access Node and a BNG for selected
use cases, including the following:

- Topology discovery
DSL Forum TR-059 identifies various queuing/scheduling mechanisms to
avoid congestion in the access network while dealing with multiple flows
with distinct QoS requirements. Such mechanisms require that the BNG
gains knowledge of the topology of the access network, the various links
being used and their respective rates. One approach to achieve this is
to send the characteristics of the local loop (e.g. DSL sync rate) at
session establishment time. In this case, the characteristics would be
added to DHCP and/or PPPoE messages by means of newly defined
sub-options. Another approach consists of sending the information by
means of a new Layer 2 Control mechanism, independent of the PPP or DHCP
session. In this case it is possible to take into account the possible
dynamic nature of the access loop (e.g. when using Seamless Rate
Adaptation).

- OAM
Traditional DSL broadband access networks employ point-to-point ATM
circuits between a CPE and a BRAS. In such an environment,
troubleshooting can be achieved by means of end-to-end ATM loopbacks. 
With Ethernet getting a more important role as layer 2 technology in the
aggregation network, operators require to keep ways to test and
troubleshoot connectivity in the case of a mixed Ethernet and ATM access
network (including the local loop). To reach consistency with ATM based
broadband access networks, a layer 2 control mechanism can be introduced
between a BNG and an Access Node, allowing to trigger the OAM mechanism
used on the local loop.

In the context of PD-021v2, a protocol analysis was performed to find
the best solution to achieve "Layer 2 Control". PD-021v2 recommends
achieving these concepts based on the General Switch Management Protocol
(GSMPv3). It was concluded that the full set of GSMP was not needed to
drive Layer 2 Control messages, and that GSMPv3 needed to be extended
with new parameters and message types.

This working group is responsible for investigating which subset of
GSMPv3 is required for l2c and which extensions are to be specified for
the selected use cases. It will also respond to protocol issues that
arise during implementation of the current specifications.

Finally, this working group will investigate possible extensions of the
above concepts to obtain broader applicability. In this context, the
following will be addressed:

- Use of l2c over non-DSL access technologies Alternate broadband access
technologies such as PON, Ethernet and Wimax will have similar
challenges to address. These technologies could benefit from the same
approach, providing a unified control and management architecture for
multiple access technologies, hence facilitating migration from one to
the other and/or parallel deployments.

- l2c support over a lightweight transport The working group will
investigate the possibility of mapping GSMP over a lighter transport
such as IP or UDP.

Goals and Milestones:

April 2006	Document l2c Framework and Requirements (based on DSL
Forum work)
May 2006	Initial WG Internet-Draft defining the subset of the
GSMPv3 
protocol and extensions to achieve Topology Discovery, OAM and Line
Configuration in a DSL environment
August 2006	Submit the l2c Framework and Requirements to IESG for 
Proposed Standard
September 2006	Submit the GSMPv3 extensions to achieve Topology 
Discovery, OAM and Line Configuration in a DSL environment to IESG for
Proposed Standard
December 2006	Define GSMPv3 extensions for the mapping over a 
lightweight transport mechanism
February 2007	Submit the extensions of GSMPv3 to achieve Topology 
Discovery and Line Configuration in a DSL environment to IESG for Draft
Standard
March 2007	Define GSMPv3 extensions to achieve Topology Discovery
in a 
non-DSL environment (e.g. PON, Wimax)
June 2007	Sumbit the GSMPv3 extensions for the mapping over a 
lightweight transport mechanism to IESG for Proposed Standard
September 2007	Sumit GSMPv3 extensions to achieve Topology Discovery in

a non-DSL environment to IESG for Proposed Standard
September 2007	Re-charter or conclude Working Group

Internet-Drafts:
GSMP extensions for layer2 control (L2C) - Topology Discovery and Line
Configuration <draft-wadhwa-gsmp-l2control-configuration-02.txt>

_______________________________________________
L2cp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2cp

_______________________________________________
L2cp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2cp

---

From: [email-masked]
Date: Fri, 20 Jan 2006 18:23:14 +0100

Hi Kim,

thanks for the feedback. I've got sympathy for the idea to identify a 
track on "analyzing additional use cases", and let line configuration 
fall under that one. At the same time I have some concerns that these 
newer use cases may lack the level of consensus required to have a 
successful BOF and agreed upon charter. Having a crisp scope and 
avoiding loose charter statements key to be able to get started.

What do others on this list think?

Regards,
Sven

-- 
.--------------------------------------------------.
| Sven Ooghe                                       |
| Access Network Division, CTO                     |
| Alcatel                                          |
| Francis Wellesplein, 1     Tel : + 32 3 240 4226 |
| B-2018 Antwerpen, Belgium  Fax : + 32 3 240 9904 |
.--------------------------------------------------.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 20 Jan 2006 16:41:39 -0800

Hi folks.

Please keep up the discussion here, it really helps when ADs need to 
make decisions about BoF scheduling and the like.

I've cc'd the Operations and Management area directors (who I will ask 
to subscribe to the list if they have not already). It's likely that 
this WG would be targeted in their area vs. the Internet Area (I've had 
an initial discussion with Bert, and we came to that agreement). This 
shouldn't matter too much for you guys, just a different set of ADs to 
work with.

Thanks,

- Mark

[email-masked] wrote:

>> GSMPv3 protocol and extensions to achieve Topology Discovery, OAM and 
>> Line
>> in a non-DSL environment (e.g. PON, Wimax)