Subject: [L2CP] IETF L2CP Framework and Requirements

From: [email-masked]
Date: Tue, 28 Feb 2006 12:55:13 +0100

All,

As some of you on this list probably know, Norbert, Michel and myself are involved in the DSL Forum work on a proposed Working Text covering the concept of Layer 2 Control in Broadband Multi-Service Architectures (WT-147). This is linked to the activities and discussions on this list.

In preparation of the IETF BOF session, we considered it would be important that there would remain some alignment between the IETF activities and the DSL Forum discussions. This would especially hold for the IETF "Framework and Requirements" document.

In preparation of the BOF session, we therefore prepared an IETF draft titled "Framework and Requirements or a Layer 2 Control Protocol (L2CP) in Broadband Multi-Service Networks" (attached for your reference). We would like to request a slot to discuss this at the upcoming L2CP BOF session in Dallas. We believe that having such a draft ready for the BOF will be beneficial for its success.

The document is based on what is proposed for WT-147. We need to discuss how this draft and draft-wadhwa-gsmp-l2control-configuration-0x.txt evolve in relation to each other, in order to reduce overlap to the extent possible.

We also discussed the concerns regarding the scope of this document and proposed DSL Forum WT-147. We would like to ensure that the activities in both standards bodies remain synchronized.

The submission deadline for first drafts was yesterday, so you should see the draft appear on the IETF exploder shortly. This deadline is before we will have had a chance to present the scope of WT-147 in the DSL Forum Architecture and Transport working group. We expect the draft should take into account the future discussions at the DSL Forum.

Comments are welcomed.

Best regards,
Sven, Norbert, Michel and Thomas

Network Working Group                                           S. Ooghe
Internet-Draft                                                   Alcatel
Expires: July 5, 2006                                           N. Voigt
                                                                 Siemens
                                                              M. Platnic
                                                                     ECI
                                                                 T. Haag
                                                               T-Systems
                                                            January 2006

  Framework and Requirements for a Layer 2 Control Protocol (L2CP) in
                    Broadband Multi-Service Networks
                   draft-ooghe-l2cp-framework-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The purpose of this document is to define a framework for a Layer 2
   Control Protocol (L2CP) mechanism between a service-oriented layer 3

Ooghe, et al.             Expires July 5, 2006                  [Page 1]

Internet-Draft               L2CP Framework                 January 2006

   edge device (e.g. a BRAS) and a layer 2 Access Node (e.g. a DSLAM) in
   a multi-service architecture.  This mechanism allows to perform QoS-
   related, service-related and subscriber-related operations.  The
   Layer 2 Control mechanism ensures the transmission of the information
   does not need to go through distinct element managers but rather
   using a direct device-device communication.  This document does not
   specify design requirements for network elements.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  3
   2.  General Design Aspects . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Concept of a Layer 2 Control Plane . . . . . . . . . . . .  4
     2.2.  Reference Architecture . . . . . . . . . . . . . . . . . .  5
       2.2.1.  Home Gateway . . . . . . . . . . . . . . . . . . . . .  6
       2.2.2.  Access loop  . . . . . . . . . . . . . . . . . . . . .  6
       2.2.3.  Access Node  . . . . . . . . . . . . . . . . . . . . .  6
       2.2.4.  Access Node uplink . . . . . . . . . . . . . . . . . .  6
       2.2.5.  Aggregation Network  . . . . . . . . . . . . . . . . .  7
       2.2.6.  Broadband Network Gateway  . . . . . . . . . . . . . .  7
     2.3.  Operation and Management . . . . . . . . . . . . . . . . .  7
       2.3.1.  Port Addressing Scheme . . . . . . . . . . . . . . . .  7
   3.  Layer 2 Control use cases  . . . . . . . . . . . . . . . . . .  9
     3.1.  Access Topology Discovery  . . . . . . . . . . . . . . . .  9
     3.2.  Line Configuration . . . . . . . . . . . . . . . . . . . .  9
     3.3.  OAM in a mixed ATM/Ethernet Environment  . . . . . . . . . 10
     3.4.  OAM in Ethernet Layer 2 Context  . . . . . . . . . . . . . 11
     3.5.  Multicast  . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Policy Server Interaction  . . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

Ooghe, et al.             Expires July 5, 2006                  [Page 2]

Internet-Draft               L2CP Framework                 January 2006

1.  Introduction

   DSL technology is widely deployed for Broadband Access for Next
   Generation Networks.  Several documents including DSL Forum TR-058
   [TR-058] and DSL Forum TR-059 [TR-059] describe possible
   architectures for these access networks.  Also, with the rise of
   supporting more bandwidth hungry services such as IPTV, architectures
   based on Ethernet access/aggregation get increasingly important (work
   on these architecture concepts are nearing completion at the DSL
   Forum).  In the scope of these architectures is the delivery of
   voice, video and data services.

   The framework defined in this document is focused on the control
   interaction between network elements and mainly targeted at DSL based
   access (either by means of ATM over DSL or as Ethernet over DSL);
   however the framework is open to non-DSL technologies, like PON, FTTx
   and WiMAX.

   Traditional architectures require permanent ATM virtual circuit(s)
   per subscriber.  Such a virtual circuit is configured on layer 2 and
   terminated at the first layer 3 device (e.g.  BRAS).  Beside the data
   plane, the models define the architectures for element, network and
   service management.  But due to organizational boundaries between
   departments operating the access loop, departments operating the ATM
   network, and departments operating the IP network, interworking at
   the management plane is not always possible.  Besides, management
   networks are usually not designed to transmit management data between
   the different entities in real time.

   When deploying value-added services across DSL access networks,
   special attention regarding Quality of Service and service control is
   required, which implies a tighter coordination between network nodes
   (e.g.  Access Nodes and Broadband Network Gateway), without burdening
   the OSS layer with unpractical expectations.

1.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Ooghe, et al.             Expires July 5, 2006                  [Page 3]

Internet-Draft               L2CP Framework                 January 2006

2.  General Design Aspects

   In this section first the concept of the Layer 2 Control Plane is
   described.  Then, the reference network is described where the Layer
   2 Control Plane is introduced.

2.1.  Concept of a Layer 2 Control Plane

   The high-level communication framework for a Layer 2 Control Plane is
   defined in Figure 1.  The Layer 2 Control Plane defines a general-
   purpose mechanism for multiple network scenarios with an extensible
   communication scheme, addressing the different use cases that are
   described throughout this document.

                               Information Reports
                            -------------------------->

                                Control Requests
                            <--------------------------

                                Control Replies
                            -------------------------->

   +-----+   +-----+   +--------+                 +-----+
   | CPE |---| HGW |---|        |                 |     |
   +-----+   +-----+   | Access |   +---------+   |     |   +--------+
                       |  Node  |---| Aggreg. |---| BNG |---| Policy |
   +-----+   +-----+   |        |   |  Node   |   |     |   | Server |
   | CPE |---| HGW |---|        |   +---------+   |     |   +--------+
   +-----+   +-----+   +--------+                 +-----+

                              Layer 2 Control Plane
                            <------------------------->

                                  PPP, DHCP, IP
     <---------><------------------------------------->

   Figure 1

   From a functional perspective, a number of functions can be
   identified:

   o  A controller function: this function is used to either send out
      requests for information to be used by the network element where
      the controller function resides, or to trigger a certain behavior
      in the network element where the reporting and/or enforcement
      function resides;

Ooghe, et al.             Expires July 5, 2006                  [Page 4]

Internet-Draft               L2CP Framework                 January 2006

   o  A reporting and/or enforcement function: the reporting function is
      used to convey status information to the controller function that
      requires the information for executing local functions.  An
      example of this is the transmission of an access loop rate from an
      Access Node to a Broadband Network Gateway (BNG) tasked with
      shaping traffic to that rate.  The enforcement function is
      contacted by the controller function to trigger a local action.
      An example of this is the initiation of a port testing mechanism
      on an Access Node.

   The connectivity between the Access Node and the BNG may differ
   depending on the actual layer 2 technology used (ATM or Ethernet).
   Therefore the identification of unicast & multicast flows/channels
   will also differ (see also Section 2.3.1).

   The control plane interactions are transactional in nature and imply
   a reliable communication channel to share states.  Bidirectional
   operations are needed, as well as dynamic negotiation of capabilities
   to address transition issues.

   The use cases in this document are described in an abstract way,
   independent from any actual protocol mapping.  The actual protocol
   specification is out of scope of this document, but there are certain
   characteristics of the protocol required such as to simplify
   specification, implementation, debugging & troubleshooting, but also
   to be easily extensible in order to support additional use cases.

2.2.  Reference Architecture

   The reference architecture used in this document can be based on ATM
   or Ethernet access/aggregation.  Specifically:

   o  In case of a legacy ATM aggregation network that is to be used for
      the introduction of new QoS-enabled IP services, the architecture
      builds on the reference architecture specified in DSL Forum TR-
      059;

   o  In case of an Ethernet aggregation network that supports new QoS-
      enabled IP services (including Ethernet multicast replication),
      the architecture builds on the Ethernet bridging/switching
      concepts defined in IEEE 802, combined with a number of protocol
      operations (PPPoE, DHCP, ARP, IGMP), security extensions and
      multicast operation that is being worked out by the DSL Forum
      (work on these architecture concepts are nearing completion).

   Given the industry's move towards Ethernet as the new access and
   aggregation technology for triple play services, the primary focus
   throughout this document is on Ethernet access/aggregation.  However

Ooghe, et al.             Expires July 5, 2006                  [Page 5]

Internet-Draft               L2CP Framework                 January 2006

   the concepts are equally applicable to an ATM architecture based on
   TR-059.

   The Layer 2 Control mechanism MUST be defined in a way that is
   independent of the underlying layer 2 transport technology.
   Specifically, the Layer 2 Control mechanism MUST support transmission
   over an ATM as well as over an Ethernet aggregation network.

2.2.1.  Home Gateway

   The Home Gateway (HGW) connects the different Customer Premises
   Equipment (CPE) to the Access Node and the access network.  In case
   of DSL, the HGW is a DSL modem that could either operate as a layer 2
   bridge or as a layer 3 router.  In the latter case, such a device is
   also referred to as a Routing Gateway (RG).

2.2.2.  Access loop

   The access loop ensures physical connectivity between the Network
   Interface Device (NID) at the customer premises, and the Access Node.
   Legacy protocol encapsulations use multi-protocol encapsulation over
   AAL5, defined in RFC2364.  This covers PPP over Ethernet (PPPoE,
   defined in RFC2516), bridged IP (IPoE) and routed IP (IPoA, defined
   in RFC2225).  Next to this, PPPoA as defined in RFC2364 can be used.
   Future scenarios include cases where the access loop supports direct
   Ethernet encapsulation (e.g. when using VDSL).

2.2.3.  Access Node

   The Access Node is a network element that terminates the access
   loops.  It supports one or more access loop technologies and allow
   them to inter-work with a common aggregation network technology.  For
   example, an access node can support ADSL2+, VDSL2 and BPON as access
   loop types and then backhaul the data to the aggregation network
   using Ethernet.  There is an emerging requirement that Access Nodes
   support multiple access loop technologies, rather than only one.

   The framework defined by this document is targeted at DSL based
   access (either by means of AAL5/ATM/DSL or as Ethernet/DSL); however
   the framework is open to non-DSL technologies, like PON, FTTx and
   WiMAX.

   The reporting and/or enforcement function defined in Section 2.1
   typically resides in an Access Node.

2.2.4.  Access Node uplink

   The fundamental requirements for the Access Node uplink are to

Ooghe, et al.             Expires July 5, 2006                  [Page 6]

Internet-Draft               L2CP Framework                 January 2006

   provide traffic aggregation, Class of Service distinction and
   customer separation and traceability.  This can be achieved using an
   ATM or an Ethernet based technology.

2.2.5.  Aggregation Network

   The aggregation network provides traffic aggregation towards the
   BNG(s).  The aggregation technology can be based on ATM (in case of a
   TR-059 architecture) or Ethernet (cf. the architecture work performed
   by the DSL Forum).

2.2.6.  Broadband Network Gateway

   The Broadband Network Gateway (BNG) is an IP Edge Router where
   bandwidth and QoS policies may be applied.  The BRAS is a specific
   BNG that provides aggregation capabilities (e.g.  IP, PPP, Ethernet)
   between the access network and the Network Service Provider or
   Application Service Provider.  Beyond aggregation, it is also an
   injection point for policy management and IP QoS in the access
   network.  The BNG interfaces to the aggregation network by means of
   standard ATM or Ethernet interfaces, and towards the regional
   broadband network by means of transport interfaces for Ethernet
   frames (e.g.  GigE, Ethernet over SONET).  The BNG supports the Layer
   2 Control functionality defined for the respective use cases
   throughout this document.  The controller function defined in
   Section 2.1 typically resides in a BNG.

2.3.  Operation and Management

   When introducing a Layer 2 Control Plane, care is needed to ensure
   that the existing management mechanisms remain operational as before.

   Specifically when using the Layer 2 Control Plane for performing a
   configuration action on a network element, one gets confronted with
   the challenge of supporting multiple managers for the same network
   element: both the Element Manager as well as the Layer 2 Controller
   function may now perform configuration actions on the same network
   element.  Conflicts therefore need to be avoided.

   Also, when using the Layer 2 Control Plane for performing a reporting
   action, there is a possibility to integrate this with a central
   Policy Management system that keeps track of the different subscriber
   related parameters (e.g. access loop bitrate).

2.3.1.  Port Addressing Scheme

   In deployments using an ATM aggregation network, access loop
   identification is facilitated by the typical one-to-one mapping

Ooghe, et al.             Expires July 5, 2006                  [Page 7]

Internet-Draft               L2CP Framework                 January 2006

   between an access loop and ATM PVC between the Access Node and the
   BNG.  Based on such property, in a PPP scenario, the BNG typically
   includes a NAS-Port-Id (or NAS-Port in some cases) attribute in
   RADIUS authentication & accounting packets sent to the RADIUS
   server(s).  Such attribute includes the identification of the ATM VC
   for this subscriber, which allows in turn identifying the access
   loop.

   In an Ethernet based aggregation network, two different port
   addressing schemes can be used (cf. the architecture work performed
   by the DSL Forum):

   o  A first approach is to use a one-to-one VLAN assignment model for
      all DSL ports.  This allows the access loop identification to be
      directly derived from the VLAN tagging, i.e.  S-VLAN ID or <S-VLAN
      ID, C-VLAN ID> pair, of the frames coming from this DSL port;

   o  A second approach is to use a many-to-one VLAN assignment model
      and to encode the access loop identification in the "Agent Circuit
      ID" sub-option to be added to a DHCP or PPPoE message.  The
      details of this approach are being specified by the DSL Forum.

   This document assumes that the port addressing scheme should be based
   on what will be specified by the DSL Forum.  It should be noted
   however that the use of such a scheme does not imply the actual
   existence of a PPPoE or DHCP session, nor on the specific
   interworking function present in the Access Node.  In some cases, no
   PPPoE or DHCP session may be present, while the port addressing would
   still be desirable.

Ooghe, et al.             Expires July 5, 2006                  [Page 8]

Internet-Draft               L2CP Framework                 January 2006

3.  Layer 2 Control use cases

3.1.  Access Topology Discovery

   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 a BNG
   (e.g. a BRAS) gains knowledge about the topology of the access
   network, the various links being used and their respective rates.
   Some of the information required is somewhat dynamic in nature (e.g.
   DSL sync rate), hence cannot come from a provisioning and/or
   inventory management OSS system.  Especially, when the access loop is
   operated in Rate Adaptive Mode (RAM) it is very important to enforce
   consistency of such data.

   When using an Ethernet-based aggregation network, there is no longer
   a "logical circuit" or "logical path" terminated on the layer 3
   device (e.g.  BNG), as a representation of the access loop.  That
   creates in turn some challenges to properly configure the BNG and its
   hierarchical scheduler.

   Dynamic and automated discovery of the access network topology
   addresses these issues.  The control plane allows the Access Node
   (e.g.  DSLAM) to communicate to the BNG access network topology
   information and any corresponding updates.

   Topology Discovery is specifically important in case the data rate of
   the access loop changes overtime.  Topology Discovery may actually
   include more information than link identification and corresponding
   data rates, notably for the access loop such as Interleaving Delay or
   Minimum and Maximum attainable rates.

   The topology and the rates of the various links to enable the BNG
   hierarchical scheduling and policing mechanisms are the following:

   o  The identification and speed (rate) of the access loop (DSL sync
      rate)

   o  The identification and speed (rate) of the Remote Terminal/Access
      Node link (when relevant)

   The BNG can adjust downstream shaping to current access loop rate,
   and more generally re-configure the appropriate nodes of its
   hierarchical scheduler.

3.2.  Line Configuration

   Access loop rates are typically configured in a static way.  If a

Ooghe, et al.             Expires July 5, 2006                  [Page 9]

Internet-Draft               L2CP Framework                 January 2006

   subscriber wants to change its access loop rate, this requires a
   reconfiguration of the access loop via the network operator, possibly
   implying a business-to-business transaction between an Internet
   Service Provider and an Access Provider.

   A Layer 2 Control mechanism supports a more flexible approach for
   supporting "bandwidth on demand".  Triggered by topology information
   as assisted by Access Topology Discovery described in Section 3.1,
   the BNG could query a policy server (e.g.  RADIUS server) to retrieve
   line configuration data.  Most of the subscriber related service
   configuration is typically enforced at the BNG, but there are a few
   cases where it can be useful to push such service parameters to the
   Access Node for local enforcement of a mechanism (e.g.  DSL related)
   on the corresponding access loop.  The BNG may send line
   configuration information to the Access Node using Subscriber Request
   messages.  The BNG may also update the line configuration due to a
   subscriber service change (e.g. triggered by the policy server).
   Using a Layer 2 Control plane, the BNG achieves such goal by an
   interoperable and standardized protocol.

   Using such approach simplifies the OSS infrastructure for service
   management, allowing to fully centralize subscriber-related service
   data (e.g.  RADIUS server back-end) and avoiding complex cross-
   organization business-to-business interactions.

   More generally, several service/subscriber DSL parameters (e.g. rate,
   inter-leaving delay) can benefit from such flexible approach to
   enable a "service on demand" model.  One way to change line
   parameters is by using profiles.  These profiles (DSL profiles for
   different services) are pre-configured by the Element Manager that is
   managing the Access Nodes.  The Layer 2 Control interaction then only
   needs to transmit a reference to the right DSL profile.  Another way
   to change line parameters is by conveying discrete DSL parameters in
   the Layer 2 Control interaction.

3.3.  OAM in a mixed ATM/Ethernet Environment

   Traditionally, ATM circuits are point to point connections between
   the BNG and the DSLAM or modem.  In order to test the connectivity on
   layer 2, appropriate OAM functionality is used for operation and
   troubleshooting.  By migrating to Ethernet-based aggregation
   networks, such ATM OAM functionality is no longer applicable.  From
   an operator's point of view, it is still required to keep the same
   ways to test and troubleshoot connectivity in such a mixed Ethernet
   and ATM access network (including the access loop).  Corresponding
   control plane functions must be envisioned.  In an existing ATM
   architecture an end to end OAM loopback is performed between the edge
   devices (BRAS and modem/RG) of the access network.  To reach

Ooghe, et al.             Expires July 5, 2006                 [Page 10]

Internet-Draft               L2CP Framework                 January 2006

   consistency in the operation of the access network, an appropriate
   functionality must be implemented.  A Layer 2 Control plane between
   BNG and Access Node can close the gap which currently occurs by
   migrating to Ethernet, until appropriate native Ethernet OAM standard
   mechanisms are ratified.

   Triggered by a local management interface, the BNG can initiate a
   loop test between Access Node and modem/RG via a Layer 2 Control
   operation.  A Subscriber Request is sent to the Access Node, which
   triggers on the access loop either an ATM F5 loopback test in case of
   sending ATM cells over the access loop, or a port synchronization and
   administrative test in case of sending Ethernet frames over the
   access loop.  A Subscriber Response is sent by the Access Node to the
   BNG, which may report results via a local management interface.
   Thus, the connectivity between the BNG and the modem/RG can be
   monitored by a single trigger event.

3.4.  OAM in Ethernet Layer 2 Context

   From an operator's point of view, once Ethernet technology is used
   between the BNG and the modem/RG, similar end-to-end OAM mechanisms
   are desired as used to be applied by ATM OAM.  Unfortunately there is
   no comparable data structure for Ethernet-based Access Nodes because
   the OAM mechanisms based on IEEE802.3ah or IEEE802.1ag are still
   being discussed.  When Ethernet based VDSL2 access is present, a port
   status test triggered by the BNG EMS and conveyed via a Layer 2
   Control Plane could be seen as workaround.

3.5.  Multicast

   With the rise of supporting IPTV services in a resource efficient
   way, multicast services are getting increasingly important.  This
   especially holds for an Ethernet based access/aggregation
   architecture.  In such a model, typically IGMP is used to control the
   multicast content replication process.  This is achieve by means of
   IGMP snooping or IGMP proxy in the different layer 2 nodes in the
   network (e.g.  DSLAM, Ethernet aggregation switch).  In such a
   context it needs to be seen if and how the Layer 2 Control Plane
   applies to such multicast based applications.

Ooghe, et al.             Expires July 5, 2006                 [Page 11]

Internet-Draft               L2CP Framework                 January 2006

4.  Policy Server Interaction

   This document does not consider the specific details of the
   communication with a policy server (e.g. using RADIUS).

Ooghe, et al.             Expires July 5, 2006                 [Page 12]

Internet-Draft               L2CP Framework                 January 2006

5.  Security Considerations

   This document does not consider additional security considerations.

Ooghe, et al.             Expires July 5, 2006                 [Page 13]

Internet-Draft               L2CP Framework                 January 2006

6.  Acknowledgements

   The authors would like to thank everyone that has provided comments
   or input to this document.  In particular, the authors acknowledge
   the work done by the contributors to DSL Forum PD-021, which contains
   parts of the rationale described in this document.

Ooghe, et al.             Expires July 5, 2006                 [Page 14]

Internet-Draft               L2CP Framework                 January 2006

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

7.2.  Informative References

   [TR-058]  Elias, M. and S. Ooghe, "Multi-Service Architecture &
             Framework Requirements", DSL Forum TR-058, September 2003.

   [TR-059]  Anschutz, T., "DSL Evolution - Architecture Requirements
             for the Support of QoS-Enabled IP Services", DSL Forum TR-
             059, September 2003.

Ooghe, et al.             Expires July 5, 2006                 [Page 15]

Internet-Draft               L2CP Framework                 January 2006

Authors' Addresses

   Sven Ooghe
   Alcatel
   Francis Wellesplein 1
   B-2018 Antwerp
   Belgium

   Phone: +32 3 240 42 26
   Email: [email-masked]

   Norbert Voigt
   Siemens
   Siemensallee 1
   17489 Greifswald
   Germany

   Phone: +49 3834 555 771
   Email: [email-masked]

   Michel Platnic
   ECI
   30 Hasivim Street
   Petakh Tikva
   Israel

   Phone: + 972 3 926 85 35
   Email: [email-masked]

   Thomas Haag
   T-Systems
   Deutsche Telekom Allee 7
   64295 Darmstadt
   Germany

   Phone: +49 6151 937 5347
   Email: [email-masked]

Ooghe, et al.             Expires July 5, 2006                 [Page 16]

Internet-Draft               L2CP Framework                 January 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Ooghe, et al.             Expires July 5, 2006                 [Page 17]


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

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 28 Feb 2006 22:52:00 -0500

Sven 
   This draft seems to be a subset and to a large extent re-iteration (some of it verbatim) of draft-wadhwa-gsmp-l2control-config.txt. While the latter contains GSMP in the name, it's content sufficiently captures the L2C concept, framework (and use cases) and mechanism/details of a protocol to implement some of the use cases. It provides enough context for the BOF, both in terms of a framework and a protocol mechanism (providing proof of concept since there are interoperable DSLAM and BNG implementations based on this protocol). While I do see it useful to break the existing ID (draft-wadhwa-gsmp-l2control-config.txt) into a framework and a protocol draft, I don't see the point of starting a parallel effort with a brand new ID (reflecting content already present in the existing draft). As far as the framework is concerned , do you see a reason why this already existing draft can not be kept in sync with DSL forum work (which is just getting underway in the form of 
WT-147) ? 
Post-BOF, what we do need is detailed L2C requirements per network element (BNG, access-node, and the CPE). These detailed requirements are not explicitly covered anywhere (including in the draft you announced below, even though the name suggests so). Based on the duscussions in the BOF, I suggest that interested contributors of existing DSLF and IETF documents, work togethter to come up with an ID covering the detailed requriements (to the granulairty of network elements). 

-Sanjay

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, February 28, 2006 6:55 AM
>To: [email-masked]; Voigt Norbert; [email-masked]; 
>Sven Ooghe
>Subject: [L2CP] IETF L2CP Framework and Requirements
>
>
>All,
>
>As some of you on this list probably know, Norbert, Michel and 
>myself are involved in the DSL Forum work on a proposed 
>Working Text covering the concept of Layer 2 Control in 
>Broadband Multi-Service Architectures (WT-147). This is linked 
>to the activities and discussions on this list.
>
>In preparation of the IETF BOF session, we considered it would 
>be important that there would remain some alignment between 
>the IETF activities and the DSL Forum discussions. This would 
>especially hold for the IETF "Framework and Requirements" document.
>
>In preparation of the BOF session, we therefore prepared an 
>IETF draft titled "Framework and Requirements or a Layer 2 
>Control Protocol (L2CP) in Broadband Multi-Service Networks" 
>(attached for your reference). We would like to request a slot 
>to discuss this at the upcoming L2CP BOF session in Dallas. We 
>believe that having such a draft ready for the BOF will be 
>beneficial for its success.
>
>The document is based on what is proposed for WT-147. We need 
>to discuss how this draft and 
>draft-wadhwa-gsmp-l2control-configuration-0x.txt evolve in 
>relation to each other, in order to reduce overlap to the 
>extent possible.
>
>We also discussed the concerns regarding the scope of this 
>document and proposed DSL Forum WT-147. We would like to 
>ensure that the activities in both standards bodies remain 
>synchronized.
>
>The submission deadline for first drafts was yesterday, so you 
>should see the draft appear on the IETF exploder shortly. This 
>deadline is before we will have had a chance to present the 
>scope of WT-147 in the DSL Forum Architecture and Transport 
>working group. We expect the draft should take into account 
>the future discussions at the DSL Forum.
>
>Comments are welcomed.
>
>Best regards,