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

From: "Kim Hyldgaard \(ST/LMD\)" <[email-masked]>
Date: Sun, 22 Jan 2006 23:04:07 +0100

Hi Sven,

Yes, this is a risk, and that's why i put a secondary suggestion: 

> 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.

Wouldn't this be a way forward? Having light weight transport and
non-DSL
technologies covered with the two most important use cases is sort of
the
foundation for L2CP. 

Br
Kim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 20. januar 2006 18:23
To: Kim Hyldgaard (ST/LMD); [email-masked]
Subject: Re: [L2CP] Draft charter for Layer 2 Control

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

Kim Hyldgaard (ST/LMD) wrote:

> 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
> 

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

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

---

From: "Peter Arberg" <[email-masked]>
Date: Sun, 22 Jan 2006 23:25:50 +0100

Hi,

I think this is a good approach, and also what we see from other WG's,
that the charter can be extended when initial goals are delivered,
and members of the WG agree.

I'm not sure however that "line configuration" need to be treated 
as a seperate use case. Could it not be included in the Topology Discovery,
if we simply extended this to talk about topology discovery and 
provisioning. Is it really a use case on its own ?

cheers,
Peter

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Kim Hyldgaard (ST/LMD)
> Sent: 22. januar 2006 23:04
> To: [email-masked]; [email-masked]
> Subject: RE: [L2CP] Draft charter for Layer 2 Control
> 
> Hi Sven,
> 
> the foundation for L2CP.

---

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

Peter, all,

I'm also in favor of getting sure we get IETF acceptance of the
foundation, and then proceed by rechartering the WG as deemed appropriate.

In fact, given that a lot of work has already been done before we
started this thread, the timing wrt delivery of the first documents
could be updated. How about having a stable framework requirements
document and protocol specification for the first use cases by July
2006? This would give us about 4 months to do the work.

Then we could proceed on the enhancements to accomplish L2CP over a
lightweight transport, as well as potential specifics for other access
technologies.

Regards,
Sven

Peter Arberg wrote:
>>>topology discovery and OAM only and get these two use cases 
>>
>>in place 
>>
>>>together with the light weight transport and non-DSL 
>>
>>technologies, and
>>
>>
>>>track, like "Analyse additional use cases" and "Investigate 
>>
>>a protocol
>>
>>
>>>In this way we specify the two first use cases, topology 
>>
>>discovery and
>>
>>
>>>topology discovery and OAM only and get these two use cases 
>>
>>in place 
>>
>>>together with the light weight transport and non-DSL 
>>
>>technologies, and
>>
>>
>>>From: [email-masked] [mailto:[email-masked]] 
>>
>>On Behalf 
>>
>>>Of [email-masked]
>>>Here's a first stab at the charter for a new working group 
>>
>>that would 
>>
>>>(Considerations for Having a Successful BOF). Having said 
>>
>>that, I've 
>>
>>>- 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
>>>When deploying value-added services across broadband access 
>>
>>networks 
>>
>>>some means of coordination between the different network 
>>
>>elements in 
>>
>>>Traditionally, the different network elements are usually 
>>
>>controlled 
>>
>>>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
>>
>>
>>>This concept is called "Layer 2 Control" (l2c), in line 
>>
>>with the ideas
>>
>>
>>>Different applications can be identified where there is a 
>>
>>desire for a
>>
>>
>>>Firstly, this working group is responsible for writing the 
>>
>>framework 
>>
>>>and requirements for Layer 2 Control. This working group 
>>
>>will consider
>>
>>
>>>Secondly, this working group will investigate a protocol 
>>
>>solution to 
>>
>>>DSL Forum TR-059 identifies various queuing/scheduling 
>>
>>mechanisms to 
>>
>>>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 
>>
>>>possible dynamic nature of the access loop (e.g. when using 
>>
>>Seamless 
>>
>>>Rate Adaptation).
>>>
>>>- OAM
>>>troubleshooting can be achieved by means of end-to-end ATM 
>>
>>loopbacks.
>>
>>>With Ethernet getting a more important role as layer 2 
>>
>>technology in 
>>
>>>access network (including the local loop). To reach 
>>
>>consistency with 
>>
>>>ATM based broadband access networks, a layer 2 control 
>>
>>mechanism can 
>>
>>>In the context of PD-021v2, a protocol analysis was 
>>
>>performed to find 
>>
>>>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
>>
>>
>>>the above concepts to obtain broader applicability. In this 
>>
>>context, 
>>
>>>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
>>
>>
>>>investigate the possibility of mapping GSMP over a lighter 
>>
>>transport 
>>
>>>such as IP or UDP.
>>>
>>>Goals and Milestones:
>>>
>>>Discovery, OAM and Line Configuration in a DSL environment 
>>
>>to IESG for
>>
>>
>>>Proposed Standard
>>>February 2007	Submit the extensions of GSMPv3 to 
>>
>>achieve Topology 
>>
>>>GSMP extensions for layer2 control (L2C) - Topology 
>>
>>Discovery and Line
>>
>>