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

From: "Sanjay Wadhwa" <[email-masked]>
Date: Mon, 23 Jan 2006 05:20:55 -0500

I believe it is important to consider all use cases currently envisaged
while defining framework and requirements. It is safer to make the
framework/requirements as least restrictive as possible. I don't really
see why the scope should be limited to use cases being implemented for
DT. PD21 currently goes beyond these two cases.. Line config and
multicast should minimally be indicated in the charter.. "analyzing
additional use cases" should apply to work beyond these four currently
known use cases i.e. down the line if we start to get more creative.

I am not entirely sure about the timeline indicated for various
goals/milestones. It might be too early to put dates here beyond dates
for requirements and the protocol support for the current use cases
(topology discovery and OAM). 
We should also add to the charter something about a MIB and making the
base protocol "graceful restart" capable. Sven, otherwise, this looks
good.

Regards
-Sanjay

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Kim Hyldgaard (ST/LMD)
>Sent: Friday, January 20, 2006 1:44 AM
>To: [email-masked]; [email-masked]
>Subject: RE: [L2CP] Draft charter for Layer 2 Control
>
>
>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
>

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

---

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

Hi Sanjay, all,

I agree we should not rule out from the start the additional use cases
that have been documented PD-021. They definitely deserve fair
discussion, both at the level of the DSL Forum as well as at the IETF.

The key question is whether these ideas should be adopted in the
proposed charter for a new WG on L2CP. I think the primary objective now
is to get the ball rolling. We MUST make the BOF a successful one. It is
my understanding that in order to achieve this, we have to avoid by all
means that there would be lack of consensus on any item, how small it
might be.

I think that the current use cases topology discovery, line
configuration and OAM have had a fair amount of discussion already and I
am confident that this forms the foundaction of L2CP.

The other use cases that have been documented in PD-021 are the result
of discussions with a number of DSL Forum folks. That's good and we
should definitely continue this track to understand the value
proposition and proposed solution(s). Same applies to yet to be
identified use cases (if any). But note that these still need to be
discussed with a broader audience. I think that this will take some time
- at least it will take beyond Feb 3 to settle on that (that's when we
need to have the draft charter ready!).

So I propose that we continue the discussion on these new topics on this
list and consider the input to rechartering the working group when the
time is right.

I agree that we shouldn't put dates for the work items beyond protocol
support for the current use cases. And adding MIB aspects looks good as
well.

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