Internet Engineering Task Force E. Haleplidis Internet-Draft Intended status: Informational J. Hadi Salim Expires: May 7, 2020 Mojatatu Networks J. Chung Viasat November 4, 2019 ForCES-based BNG draft-haleplidis-forces-bng-00 Abstract This document provides an approach for the separation of the forwarding and control plane for the Broadband Network Gateway (BNG) using IETF's ForCES architecture. The document provides an initial primer on ForCES as well as an initial ForCES XML model that describes some basic functions of the BNG. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 7, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Haleplidis, et al. Expires May 7, 2020 [Page 1] Internet-Draft ForCES-based BNG November 2019 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 3. ForCES overview . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. ForCES protocol . . . . . . . . . . . . . . . . . . . . . 5 3.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . 7 3.3. ForCES & BNG . . . . . . . . . . . . . . . . . . . . . . 8 4. Basic BNG ForCES model . . . . . . . . . . . . . . . . . . . 9 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. PPPoE Discovery stage . . . . . . . . . . . . . . . . 12 4.1.2. PPP Session stage . . . . . . . . . . . . . . . . . . 13 4.2. Subscriber Information Configuration . . . . . . . . . . 13 4.2.1. Supporting multiple access types . . . . . . . . . . 16 4.3. Traffic monitoring . . . . . . . . . . . . . . . . . . . 17 5. Advanced BNG Services . . . . . . . . . . . . . . . . . . . . 17 5.1. Bandwidth Management Service . . . . . . . . . . . . . . 17 5.2. Stateless access control service . . . . . . . . . . . . 19 5.3. Quota Enforcement service . . . . . . . . . . . . . . . . 19 5.4. Lawful Intercept service . . . . . . . . . . . . . . . . 20 6. LFB Class Descriptions . . . . . . . . . . . . . . . . . . . 20 6.1. Port LFB . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1.1. Data Handling . . . . . . . . . . . . . . . . . . . . 20 6.1.2. Components . . . . . . . . . . . . . . . . . . . . . 21 6.1.3. Capabilities . . . . . . . . . . . . . . . . . . . . 22 6.1.4. Events . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Classifier LFB . . . . . . . . . . . . . . . . . . . . . 22 6.2.1. Data Handling . . . . . . . . . . . . . . . . . . . . 23 6.2.2. Components . . . . . . . . . . . . . . . . . . . . . 23 6.2.3. Capabilities . . . . . . . . . . . . . . . . . . . . 24 6.2.4. Events . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. PPPoE LFB . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.1. Data Handling . . . . . . . . . . . . . . . . . . . . 24 6.3.2. Components . . . . . . . . . . . . . . . . . . . . . 25 6.3.3. Capabilities . . . . . . . . . . . . . . . . . . . . 26 6.3.4. Events . . . . . . . . . . . . . . . . . . . . . . . 26 6.4. IPv4 Routing LFB . . . . . . . . . . . . . . . . . . . . 26 6.4.1. Data Handling . . . . . . . . . . . . . . . . . . . . 27 6.4.2. Components . . . . . . . . . . . . . . . . . . . . . 27 6.4.3. Capabilities . . . . . . . . . . . . . . . . . . . . 28 6.4.4. Events . . . . . . . . . . . . . . . . . . . . . . . 28 6.5. Policer LFB . . . . . . . . . . . . . . . . . . . . . . . 28 Haleplidis, et al. Expires May 7, 2020 [Page 2] Internet-Draft ForCES-based BNG November 2019 6.5.1. Data Handling . . . . . . . . . . . . . . . . . . . . 28 6.5.2. Components . . . . . . . . . . . . . . . . . . . . . 28 6.5.3. Capabilities . . . . . . . . . . . . . . . . . . . . 29 6.5.4. Events . . . . . . . . . . . . . . . . . . . . . . . 29 7. BNG ForCES XML model . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 10. Security Considerations . . . . . . . . . . . . . . . . . . . 56 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 11.1. Normative References . . . . . . . . . . . . . . . . . . 56 11.2. Informative References . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 1. Introduction This document presents IETF's ForCES architecture as a basis for the control and forwarding separation for the Disaggregated Broadband Network Gateway (BNG) [TR-101]. For contextual overview, any prescribed "experience" in this document are based on deployment experience over many years at large and small deployment environments for embedded, cloud as well as data centre environments. Some of these deployments (still operational at time of writing) have been publicly hinted at in media [media1], [media2] and [media3]. 2. Terminology and Conventions 2.1. Requirements Language 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]. 2.2. Definitions This document reiterates the terminology defined by the ForCES architecture in various documents for the sake of clarity. FE Model - The ForCES model used for describing resources to be managed/controlled. This includes three components; the modeling of individual Logical Functional Block (LFB model), the logical interconnection between LFBs (LFB topology), and the FE-level attributes, including LFB components, capabilities and events. The FE model provides the basis to define the information elements exchanged between CEs and FEs in the ForCES protocol [RFC5810]. Haleplidis, et al. Expires May 7, 2020 [Page 3] Internet-Draft ForCES-based BNG November 2019 LFB (Logical Functional Block) Class - A template that represents a resource that is being modeled. Most LFBs relate to packet processing in the data path; however, that is not always the case. LFB classes are the basic building blocks of the FE model. LFB Instance - A runtime instantiation of an LFB class. ForCES Component - A ForCES Component is a well-defined, uniquely identifiable and addressable ForCES model building block. A component has a 32-bit ID, name, type, and an optional synopsis description. These are often referred to simply as components. ForCES Protocol - Protocol that runs in the Fp reference points in the ForCES Framework [RFC3746]. ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol architecture that defines the ForCES protocol messages, the protocol state transfer scheme, and the ForCES protocol architecture itself as defined in the ForCES Protocol Specification [RFC5810]. ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in ForCES protocol architecture that uses the capabilities of existing transport protocols to specifically address protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like TCP, IP, ATM, Ethernet, etc.), and how to achieve and implement reliability, ordering, etc. the ForCES SCTP TML [RFC5811] describes a TML that is mandated for ForCES. Broadband Network Gateway (BNG) - is the network edge aggregation point used by subscribers as the access point through which they connect to the broadband network. 3. ForCES overview In this section we present a quick overview of the ForCES architecture. The reader is encouraged to read the relevant documents, in particular [RFC5810], [RFC5812] and [RFC5811]. The origins of ForCES lie in the desire to separate control and datapath; where "datapath" was intended to be packet processing resources. Over time, however, due to the convenience of the ForCES architecture it has been used for controlling and managing arbitrary (other than packet processing) resources. As long as one can abstract the resources using the ForCES model, the protocol semantics allows using ForCES protocol to control and manage said resources. Haleplidis, et al. Expires May 7, 2020 [Page 4] Internet-Draft ForCES-based BNG November 2019 In the case of the BNG, we will show later the attributes such as interfaces, user statistics and QoS parameters can all be modeled as resources. The ForCES architecture is comprised of: 1. A data model definition [RFC5812] serving as a basis for the architecture constructs acted on by the protocol. 2. The ForCES protocol (PL) [RFC5810] which acts on the model component constructs for the purpose of control/management. 3. A transport mapping layer (TML) which takes the PL constructs and maps them to underlying convenient transport(s) and then delivers them to the target end points. Currently there is only one standardized TML based on SCTP; [RFC5811]. however more could be defined - as an example QUIC [I-D.ietf-quic-transport] appears to be a very good fit. 3.1. ForCES protocol The ForCES protocol features can be summarized as: 1. Transport independence. The ForCES protocol is intended to run on a variety of chosen protocols. 2. Simplified ForCES layer when possible: * Security is left up to the transport choice keeping the ForCES layer simple. * Optional configurable Controller high availability. FEs(resource owners) when desired can connect to multiple controllers in both cold or hot standby mode [RFC5810], [RFC7121]. 3. Degrees of reliability. Deployment experience with ForCES as depicted in the SCTP TML (RFC 5811 [RFC5811]) has shown an absolute need for a variety of shades of reliability. 4. Node overload. Deployment experience has shown the need to protect against node overload in a work-conserving mode (thus optimal resource usage). 5. Transactional capabilities in the form of 2 phase commits. Haleplidis, et al. Expires May 7, 2020 [Page 5] Internet-Draft ForCES-based BNG November 2019 6. Wire Serialization and optimization. Encoding on the wire is binary. The data model is sufficient to describe the content on the wire. 7. Transactional scalability, low latency and high throughput. 8. Various execution modes for transactions {Execute-all-or-none, Execute-until-error, Execute-all-despite-errors}. 9. Communication methods. ForCES provides two communication methods for a controller to receive data from the device, namely request/response and publish/subscribe. ForCES allows the controller at any time to access (request) any resource, and allows for a controller to subscribe to any supported resources events. 10. Simple and powerful API. The ForCES architecture provides (very) few simple protocol verbs which act upon a multitude of nouns as represented by the ForCES model. The grammar could be described as: [Data] In other words, the ForCES semantic allows composing of rich services on top of the basic grammar. The expressive simplicity of the protocol is achieved due to the few verbs which act on the agreed-to modeled LFB components. The protocol is totally agnostic of the nature of the resource being controlled/managed. It is up to the modeler to describe the resource in the manner that is fitting (although frowned-upon, one could describe the resource model exactly as it is implemented and reduce the generalities and therefore translation overhead). The model is highly extensible and for this reason, the knowledge of the resource control is offloaded to the service layer and a basic infrastructure is all that is needed. The ForCES verbs are: {GET, SET, DELETE, REPORT and a few helpers}. 11. Traffic sensitive protocol level connectivity detection. ForCES layer heartbeats could be sent in either or both directions. Heartbeats, however are only sent when the link is idle. 12. Dynamic association of FEs to CEs. FEs register and unregister to controllers and advertise their capabilities and capacities. Haleplidis, et al. Expires May 7, 2020 [Page 6] Internet-Draft ForCES-based BNG November 2019 3.2. ForCES Model The ForCES Model features can be summarized as: 1. Data model modularity through LFB class definition. 2. Data model type definitions via atomic types, complex/compound types, grouping of compound types in the form of structures and indexed/keyed tables which then end up composing addressable components within an LFB class. 3. Hierarchical/tree definition of control/config/state components which is acted on by a controller via the ForCES protocol. 4. Information-modeled metadata and expectations. 5. Built in LFB class resource capability definition/advertisement. 6. Publish/subscribe LFB event model with expressive trigger and report definitions. Filters include: * Hysteresis - used to suppress generation of notifications for oscillations around a condition value. Example, "generate an event if the link laser goes below 10 or goes above 15". * Count - used to suppress event generation around occurrence count. Example, "report the event to the client only after 5 consecutive occurrences". * Time interval - used to suppress event generation around a time limit. Example, "Generate an event if table foo row hasn't been used in the last 10 minutes". 7. Data model flexibility/extensibility through augmentations, and inheritance. 8. Backward and forward compatibility via LFB design and versioning rules. 9. Formal constraints for validation of defined components. An LFB class can be seen in Figure 1. An LFB class has configurable components, read-only capabilities and subscribable events. Also an LFB class has one or more input ports where packets and/or metadata enter the LFB, and one or more output ports where packets and/or metadata exit the LFB. LFBs can be instantiated in the datapath. Haleplidis, et al. Expires May 7, 2020 [Page 7] Internet-Draft ForCES-based BNG November 2019 ^ | Control | Plane v Interface +--------------------+--------------------+ | | | +---------+ +---------+ +---------+ | | |Component| |Component| |Component| | | | A | | B | | C | | | +---------+ +---------+ +---------+ | | | | Control Block | | | +--------------------+--------------------+ | ^ | Datapath | | +-+-+ Output Datapath | +---v----+ +------->+ +---------> Input +-+-+ | | | | | +---------->+ | |Datapath+----+ +-+-+ | +------------->+Program | | Datapath +-+-+ | +----+ +-+-+ Output | +--------+ | | +--------> | +------->+ | | +-+-+ | | +-----------------------------------------+ Figure 1: LFB Model Most LFBs are related to packet processing. However there are cases such as discussed in [RFC5810] and [RFC5812] where two LFBs are defined, the FE Protocol LFB and the FE Object LFB respectively. The FE Protocol LFBs allows the control plane to configure, among others, the ForCES protocol mechanics, such as High availability and heartbeat mechanism. The FE Object LFB allows the control plane to configure, among others, the FE as whole, instantiate LFBs and manipulate the LFB service graph respectively. 3.3. ForCES & BNG The ForCES architecture accrues several benefits. ForCES has the ability to add new packet services, described as LFB graphs, in an existing infrastructure. Secondly it can natively support any type of access, fixed, mobile, simply by modeling the necessary LFBs. One of the major advantages is that these abilities come with no change to the protocol; so long as the proper models (LFBs) are introduced, the ForCES protocol inherently supports them. To illustrate these claims, this document will start first by describing a basic Haleplidis, et al. Expires May 7, 2020 [Page 8] Internet-Draft ForCES-based BNG November 2019 connectivity service and then augment that with a bandwidth management service. For more details on how ForCES can support the separation of the forwarding from the control plane in regards to the BNG, the reader is encouraged to read the Control-Plane and User-Plane (CUSP) ForCES gap analysis [I-D.haleplidis-bcause-forces-gap-analysis] which elaborates on how ForCES meets the CUSP requirements as well as provide a ForCES XML model that detailed a CUSP information model. We hope to convince the reader that there already exists a robust IETF architecture which has a large deployment experience that meets all the CUSP requirements, while being more extensible and flexible with new requirements without any changes to the protocol. 4. Basic BNG ForCES model The BNG is the network edge aggregation point used by subscribers as the access point through which they connect to the broadband network. A subscriber could get access to the network using one or more different access types through the BNG. In this draft we focus on IPv4 PPPoE access. Supporting different access types is easily done by adding appropriate LFBs that handle encapsulating and decapsulating the relevant protocol headers. As discussed in the previous section, adding new LFB models has no impact on the protocol itself. Future versions of this document will include additional access types. A BNG is comprised of many different components. Figure 2 depicts components, modeled through ForCES, required to provide subscriber access using PPPoE. It is important to note that Figure 2 does not provide implementation details, but rather is a modelling of the underlying resources. Haleplidis, et al. Expires May 7, 2020 [Page 9] Internet-Draft ForCES-based BNG November 2019 +---------------------------------------+ | +------------+ | | | Subscriber | Control | | | Information| Plane | | +------------+ | +---------------------------------------+ ^ | ForCES protocol v +---------------------------------------+ | | | +--------------+ | | | Tunneling | | | |Infrastructure| | | +--------------+ | | | | | | +----------+ +-----+ +-------+ | | |Classifier| |PPPoE| | IPv4 | | +----------+ | | LFB | | LFB | |Routing| | +-------+ | | | +----------+ +-----+ | LFB | | | | |Subscriber| | +-------+ | |Network| | | | | | | +----------+ | +------+ +------+ | +-------+ | +------+| +------+| | | +------+|| +------+|| | | | Port ||+ | Port ||+ | | | LFB |+ | LFB |+ | | +------+ +------+ | | | +---------------------------------------+ Figure 2: BNG LFB Components There are a number of steps required for a subscriber to get access to the network. These include: 1. First the subscriber has to be authenticated. This will require a number of control packets to be exchanged between the subscriber and the control plane, redirected from the forwarding plane. For PPPoE the credentials are handed off to a RADIUS server; The communication between the control plane and the RADIUS server is out of scope of this document. 2. Once the subscriber is authenticated, the control plane has to configure the forwarding plane with the subscriber information, including resource allocation, authorizing the subscriber by providing access control and subscribed services. Haleplidis, et al. Expires May 7, 2020 [Page 10] Internet-Draft ForCES-based BNG November 2019 3. Finally, as subscriber traffic is allowed through the BNG, the appropriate LFB instances are monitored by the control plane for accounting purposes either by polling or subscription to events. This would require either the control plane to poll the BNG or subscribe to accounting events from appropriate LFB instances. In the first version of the draft, we focus on PPPoE as the access control mechanism. This first stage is the discovery and authentication phase via PPPoE and PPP. 4.1. Authentication There are two stages in PPPoE [RFC2516]. The Discovery stage and the PPP Session stage that will perform the discovery and authentication respectively. Haleplidis, et al. Expires May 7, 2020 [Page 11] Internet-Draft ForCES-based BNG November 2019 +---------------------------------------+ | +------------+ | | | Subscriber | Control | | | Information| Plane | | +------------+ | +----+-----+------+---------------------+ Tunneling ^ | ^ Protocol | | | ForCES protocol | | v +-----------------+---------------------+ | | | | | +--+-----v-----+ | | | Tunneling | | | |Infrastructure| | | +--+-----+-----+ | | ^ | | | | v | | +--+-----+-+ | | |Classifier| | | | LFB | | | +----+--+--+ | | ^ | | | | | | | | v | | +------+ | +----------+ | +------+| | | +------>+------+|| | |Subscriber| | | Port ||+ | | +<------+ LFB |+ | +----------+ | +------+ | | | +---------------------------------------+ Figure 3: BNG Control Traffic handling 4.1.1. PPPoE Discovery stage During the Discovery stage, frames arrive at an Ethernet Port (Port LFB). The frames are sent to the Classifier LFB as seen in Figure 3. The Classifier LFB determines whether these frames are control packets, distinguished by ethertype 0x8863. The control frames will be redirected via a tunneling infrastructure towards the control plane. The tunneling infrastructure could be implemented by VxLAN, GRE, etc. ForCES could also be used in the case to redirect packets from the forwarding plane to the control plane. This is currently out of scope of this document. Haleplidis, et al. Expires May 7, 2020 [Page 12] Internet-Draft ForCES-based BNG November 2019 The control plane handles the control messages and sends back the responses via the tunneling infrastructure to be redirected in the data path to be sent back to the subscriber. Several control messages are exchanged in this stage between the subscriber and the controller - all recognized by the Classifier LFB, based on ethertype value 0x8863, and redirected to the control plane. At the end of the PPPoE discovery stage both peers know the Session ID and the peer's MAC address which both identify uniquely the session. At this stage the control plane knows the subscriber's Session ID and MAC address and programs the classifier. 4.1.2. PPP Session stage After the PPPoE Discovery stage has ended PPP traffic starts tp flow. Frames arrive at the ethernet Port (LFB). The frames are sent to the Classifier LFB. PPPoE data packets are now distinguished by ethertype 0x8864 but there are still control packets passing prior to the subscriber being authenticated. The Classifier LFB will distinguish control vs data packets, based on the protocol field of the encapsulated PPP header. Control packets such as LCP (0xC021), PAP (0xC023), CHAP (0xC223) and IPCP (0x8021), will be sent to the Control Plane to authenticate and authorize the Subscriber. After the subscriber has been authenticated the authentication stage is finished, an IP address will be issued and the Subscriber will be considered authenticated and authorized. 4.2. Subscriber Information Configuration At this stage the controller is ready to configure the forwarding plane with the authorized subscriber information. The control plane will create the basic connectivity service by configuring the PPP and the IPv4 Routing LFB to operate in forwarding mode in both the subscriber side direction as well as the internet side directions. The control plane will send a number of ForCES messages via the ForCES protocol to these LFBs with the parameters specific for the subscriber. The Subscriber provisioned information, such as assigned IP, Session ID, service, MAC address, can reside either in the CE or in the FE as an individual LFB. Both options are valid in ForCES case. The Haleplidis, et al. Expires May 7, 2020 [Page 13] Internet-Draft ForCES-based BNG November 2019 subscriber information, once set, will trigger a set of control commands to a number of LFBs; having it in the Control Plane will require more commands on the wire (ForCES messages) to be sent to the different LFBs. On the other hand, if the Subscriber Information rests in the data plane then less messaging is needed between control and data plane. Once the subscriber information has been configured correctly, the subscriber's traffic starts passing through as illustrated in Figure 4. The Classifier LFB will distinguish PPPoE data packets by ethertype 0x8864, session ID, and IPv4 traffic by PPP protocol header 0x0021 and send them to the PPPoE LFB (with session ID as metadata) on the DecapIn input port of the PPPoE LFB. The PPPoE LFB, once it validates the packet has arrived from an authorized subscriber based on the session ID and the MAC address, will decapsulate the IPv4 packet and send it to the IPv4 routing LFB, via the DecapOut output port. The IPv4 routing LFB will route the packets and send it out the correct port LFB on the other side to be sent into the network. Haleplidis, et al. Expires May 7, 2020 [Page 14] Internet-Draft ForCES-based BNG November 2019 +---------------------------------------+ | +------------+ | | | Subscriber | Control | | | Information| Plane | | +------------+ | +-------------------+-------------------+ ^ | ForCES Protocol v +-------------------+-------------------+ | | | | | +----------+ +-----+ | | |Classifier+--->PPPoE| | | | LFB | | LFB | | | +----+-----+ +--+--+ | | ^ | | | | | | | +------+ v +------+ | +----------+ | +------+| +-------+ +------+| | +-------+ | | | +------+|| | IPv4 | +------+|+--->+ | |Subscriber+----> Port ||+ |Routing+--->+ Port ||+ | |Network| | | | | LFB |+ | LFB | | LFB |+ | | | +----------+ | +------+ +-------+ +------+ | +-------+ | | +---------------------------------------+ Figure 4: BNG Basic Connectivity Service (Upstream) Figure 5 shows the downstream processing. When a packet is received from the network the port LFB will send the packet to the classifier LFB. The classifier LFB will select the IPv4 traffic and generate a metadata (Subscriber ID) based on the destination IP address, to be propagated to downstream LFBs, and send the packets to the IPv4 Routing LFB. The IPv4 Routing LFB perform normal routing functions, such as selecting the correct output port and decreasing TTL. and pass on the packet to the PPPoE LFB through the EncapIn port. The PPPoE LFB will encapsulate the packet with the correct PPPoE Session ID and destination MAC address and send the traffic back to the subscriber via the EncapOut port to the Port LFB with the interface index provided by the IPv4 routing LFB. Haleplidis, et al. Expires May 7, 2020 [Page 15] Internet-Draft ForCES-based BNG November 2019 +---------------------------------------+ | +------------+ | | | Subscriber | Control | | | Information| Plane | | +------------+ | +-------------------+-------------------+ ^ | ForCES Protocol v +-------------------+-------------------+ | | | +-------+ | | +-----+ | IPv4 | +----------+ | | |PPPoE+<---+Routing+<--+Classifier| | | | LFB | | LFB | | LFB | | | +--+--+ +-------+ +------+---+ | | | ^ | | v | | | +------+ +------+ | +----------+ | +------+| +------+| | +-------+ | | | +------+|| +------+|+<---+ | |Subscriber+<---+ Port ||+ | Port ||+ | |Network| | | | | LFB |+ | LFB |+ | | | +----------+ | +------+ +------+ | +-------+ | | +---------------------------------------+ Figure 5: BNG Basic Connectivity Service (Downstream) 4.2.1. Supporting multiple access types As has been discussed earlier in the document, any kind of access mechanism can be supported by the ForCES model, whether that is fixed access, or mobile or wireless, or optical. A relevant port LFB instantiation will be needed to handle traffic entering the BNG The classifier can be augmented to distinguish the packets based on their access mechanism, e.g. ethertypes for ethernet based access types and will send the packets to the relevant LFBs to be handled. This has no effect on the ForCES protocol. So long as everything has been modeled with the ForCES model, the protocol will able to control and manage the LFBs with no change. Haleplidis, et al. Expires May 7, 2020 [Page 16] Internet-Draft ForCES-based BNG November 2019 4.3. Traffic monitoring As soon as Subscriber traffic starts flowing through the BNG, it is imperative to monitor for accounting purposes. Subscriber usage monitoring can be achieved in a number of ways, with the easiest being monitoring incoming and outgoing statistics at the PPPoE LFB. The controller can either poll the LFB for said statistics, or it can subscribe to events to the PPPoE LFB and receive notifications for statistics. 5. Advanced BNG Services The BNG is composed of many more functions and components. ForCES provides the ability to provision new services. A service, in ForCES terms, is a graph of LFBs. Figure 4 and Figure 5 showcase a simple connectivity service. The operator via the control plane can provision new services by creating new graphs with existing LFBs or introducing new LFBs and composing new LFB graphs. One important detail in ForCES, as has been discussed before, is that defining or adding new LFBs has absolutely no impact on the protocol itself. 5.1. Bandwidth Management Service A service provider can introduce a bandwidth management service with no extension to the protocol. Adding rate limiting both in the upstream to the internet and downstream from the internet is simply done by adding a new LFB called policer as can be seen in Figure 6 and Figure 7. A service provider could add an instance for each subscriber to give them different bandwidth rates based on SLAs. Example 1 mbps up/3 mbps down vs 3 mbps up and 8mbps down. Haleplidis, et al. Expires May 7, 2020 [Page 17] Internet-Draft ForCES-based BNG November 2019 +---------------------------------------+ | +------------+ | | | Subscriber | Control | | | Information| Plane | | +------------+ | +-------------------+-------------------+ ^ | ForCES Protocol v +-------------------+-------------------+ | | | Decap | | +----------+In +-----+ | | |Classifier+--->PPPoE| | | | LFB | | LFB | | | +----+-----+ +--+--+ | | ^ | Decap | | | | Out | | +------+ v +------+ | +----------+ | +------+| +-------+ +------+| | +-------+ | | | +------+|| | IPv4 | +------+|+--->+ | |Subscriber+----> Port ||+ |Routing| | Port ||+ | |Network| | | | | LFB |+ | LFB | | LFB |+ | | | +----------+ | +------+ +---+---+ +--+---+ | +-------+ | | ^ | | v | | | +-+-----------+-+ | | | Policer | | | | LFB | | | +---------------+ | | | +---------------------------------------+ Figure 6: BNG Bandwidth management service (Upstream) Haleplidis, et al. Expires May 7, 2020 [Page 18] Internet-Draft ForCES-based BNG November 2019 +---------------------------------------+ | +------------+ | | | Subscriber | Control | | | Information| Plane | | +------------+ | +-------------------+-------------------+ ^ | ForCES Protocol v +-------------------+-------------------+ | | | +--------------------+ | | |Bandwidth Management| | | | LFB | | | +-+------------+-----+ | | | ^ | | |Encap | | | vIn +-------+ | | +-----+ | IPv4 | +----------+ | | |PPPoE| |Routing+<--+Classifier| | | | LFB | | LFB | | LFB | | | +--+--+ +-------+ +------+---+ | | | Encap ^ | | v Out | | | +------+ +------+ | +----------+ | +------+| +------+| | +-------+ | | | +------+|| +------+|+<---+ | |Subscriber+<---+ Port ||+ | Port ||+ | |Network| | | | | LFB |+ | LFB ++ | | | +----------+ | +------+ +------+ | +-------+ | | +---------------------------------------+ Figure 7: BNG Bandwidth management service (Downstream) 5.2. Stateless access control service In case an operator requires services like a firewall, an Access Control List (ACL) LFB can be instantiated and inserted into the graph to drop or allow packets. 5.3. Quota Enforcement service In case an operator require to perform quota enforcement, a Quota Enforcement (QE) LFB can be instantiated and inserted into the graph to drop or allow packets depending on the Subscriber SLA. Haleplidis, et al. Expires May 7, 2020 [Page 19] Internet-Draft ForCES-based BNG November 2019 5.4. Lawful Intercept service In the case of creating a Lawful Intercept, an operator simply by instantiating a mirror LFB into the datapath to create copies of the packets to be sent to a specific destination 6. LFB Class Descriptions As has been discussed before, an LFB is a well defined logical functional block residing in the FE and is an accurate abstraction of the FE's processing capabilities. This document provides a sample LFB class library pertaining to the separation of the forwarding and the control plane for the BNG. [RFC6956] provides an additional LFB class library for a typical router. 6.1. Port LFB The Port LFB abstracts all the interfaces, physical and virtual, in the device. The LFB handles frames coming in from or out of the FE. The current port class LFB is defined to receive ethernet frames. 6.1.1. Data Handling When frames arrive from the Subscriber or the Network side, these frames are received by the Port LFB via IngressInPort, the physical port of the BNG, to be passed downstream to the Classifier LFB via the IngressOutPort. When frames are meant to be sent to the Subscriber or the Network side, these frames arrive to the Port LFB via the EgressInPort alongside an ifIndex metadata to notify which interface should be used, and sent out via the EgressOutPort. Figure 8 illustrates the Port LFB Haleplidis, et al. Expires May 7, 2020 [Page 20] Internet-Draft ForCES-based BNG November 2019 ^ | Control | Plane v Interface +------------------+------------------+ | | | +------------+ | | | Ports | | | | (Component)| | | +------------+ | | | | Control Block | | | +------------------+------------------+ | ^ | IngressInPort+-+-+ | +-+-+IngressOutPort +----------->+ +------+ +---v----+ +----->+ +---------> | | | | | | | | +-+-+ +---->+Datapath+----+ +-+-+ | |Program | | +-+-+ +---->+ +----+ +-+-+ EgressInPort | | | +--------+ | | |EgressOutPort +----------->+ +------+ +----->+ +--------> +-+-+ +-+-+ | | +-------------------------------------+ Figure 8: Port LFB 6.1.2. Components This LFB has defined only one component, named ports. The ports component is table. Each entry in the table contains the parameters for a port within the BNG. All the entries consist of all the ports of the BNG. Each table entry is of type PortInfo. The PortInfo type contains the following configurable parameters: Name - A string representation for the name of the port ifindex - the interface index of the port L2Address - The MAC address of the port MTU - The maximum transmit unit for this port Stats - 64-bit counters for statistics for the port. These include Tx,Rx bytes and packets, errors and dropped packets. Haleplidis, et al. Expires May 7, 2020 [Page 21] Internet-Draft ForCES-based BNG November 2019 Operstate - The Operational state of the port, such as down, up Adminstate - The Administrative state of the port, such as down, up Promiscuity - The port promiscuity 6.1.3. Capabilities This LFB does not have a list of capabilities. 6.1.4. Events This LFB has four events specified: Port changed - This event will trigger when an existing port has been updated. Port deleted - This event will trigger when an existing port has been deleted such as deleting a virtual port or removing a physical interface. Port created - This event will trigger when an new port has been created such as creating a virtual port or inserting a physical interface. Port stats changed - This event will trigger periodically when stats change. It is important to properly configure the event parameters (hysteresis, interval) to avoid generation of multiple event notifications 6.2. Classifier LFB The classifier LFB abstracts the classification of packets into different categories. From the subscriber side to the network, it is required for the classifier LFB to detect Subscriber control traffic to be redirected to the control plane, as well as detect Subscriber data traffic to be sent downstream with the subscriber ID as metadata. From the network side to the subscriber, it is required for the classifier LFB to detect the Subscriber ID from the destination IP address and send the packet with the subscriber ID as metadata to the next LFB. In addition the classifier LFB has to discriminate control packets arriving from the control plane via the tunneling infrastructure which have to be sent back to the subscriber. Haleplidis, et al. Expires May 7, 2020 [Page 22] Internet-Draft ForCES-based BNG November 2019 6.2.1. Data Handling Packets enter the classifier LFB via the InPort. Ethernet packets arriving from the subscriber side with Ethertype 0x8863 are considered PPPoE control messages and are sent to the control plane via the RedirectOut output port. Similarly, ethernet frames with EtherType 0x8864 but the PPP protocol field belonging to a control protocol, will be sent to the control plane via the ControlOut output port Packets returning via the tunneling infrastructure enter the classifier LFB via the InPort, are matched based on destination MAC address, Ethertype and optionally PPP protocol field and are sent to the Port LFB via the EthernetOut port to be sent to the subscriber. Subscriber data traffic coming from the subscriber's side are matched based on EtherType 0x8864 and PPP protocol 0x0021 (IPv4) and also based on the PPPoE session ID and Subscriber MAC address. Once matched, the classifier will issue the Subscriber ID (configured by the control plane) and pass it along the packet as metadata to the next LFB (PPPoE LFB) via the EthernetOut port. Subscriber data traffic coming from the network's side are matched based on IPv4 destination address. Once matched, they will be issued the Subscriber ID (configured by the control plane) and pass it along to the next LFB (IPv4 Routing) via the IPv4Out port. 6.2.2. Components This LFB has one component, the filters which is the table that contains all the classification filters. Each entry in the table contains three fields: Filter Name - The name of the filter Actions - A table of actions to be performed on the packet Filter keys - A table of key values to be matched on the packets In regards to the Actions, each table entry of the actions contains two fields: Action Type - The name of the action Actions - The action itself. Currently only three actions have been defined, drop forward and redirect to the controller Haleplidis, et al. Expires May 7, 2020 [Page 23] Internet-Draft ForCES-based BNG November 2019 In regards to the Filter keys, each table entry of the filter keys contains five optional fields: IP protocol - Detects a specific transport protocol Ethernet - Matches on specific ethernet fields IP - Matches on specific IPv4 header fiels PPP Control - To detect and match specific PPP control messages PPP Subscriber traffic - To detect PPP subscriber data traffic 6.2.3. Capabilities This LFB does not have a list of capabilities. 6.2.4. Events This LFB has three events specified: Filter Changed - An Existing filter has been changed. Filter deleted - This event will trigger when an existing filter has been deleted. Filter created - This event will trigger when a new filter has been created. 6.3. PPPoE LFB The PPPoE LFB is responsible for Encapsulating IPv4 Packets into PPPoE Ethernet frames coming from the network side towards the subscriber, and decapsulating IPv4 Packets from PPPoE frames arriving from the subscriber to be sent to the network. 6.3.1. Data Handling This LFB handles traffic different depending on whether it needs to be encapsulated into an PPPoE frame or decapsulate a PPPoE frame and the IPv4 packet from within. Regarding encapsulation, IPv4 packets arrive from the network side via the EncapIn port alongside the subscriber ID generated by the classifier LFB and the OutIfIndex metadata generated by the IPv4 routing LFB. The LFB looks up the subscriber information and creates the PPPoE frame based on the information located in the PPPoE Subscriber Information table entry. The generated frame is sent to Haleplidis, et al. Expires May 7, 2020 [Page 24] Internet-Draft ForCES-based BNG November 2019 the Port LFB via the EncapOut port to the port specified by the OutIfIndex. Regarding decapsulation, PPPoE frame arrive from the subscriber side via the DecapIn port alongside the subscriber ID generated by the classifier LFB. The LFB looks up the subscriber information and decapsulates the IPv4 packet within. The resulting IPv4 packet is sent to the IPv4 Routing LFB via the DecapOut port. 6.3.2. Components This LFB has two components, the first is the PPPoE Subscriber Information and the second are the Encap and Decap Statistics for encapsulating and decapsulating packets. Both components are tables. Each entry in the PPPoE Subscriber Information table contains the following: Subscriber ID - The subscriber identifier. This value is also used to look up table entries. PPPoE Session ID - The Session ID of the Subscriber Subscriber MAC Address - The Subscriber's MAC Address Local MAC Address - The MAC Address of the local interface connected to the Subscriber. MSS - The Maximum Segment Size MRU - The Maximum Receive Unit Magic Number - The magic number Peer Magic Number - The subscriber's magic number Each entry in the Statistics table contains the following: Subscriber ID - The subscriber identifier. This value is also used to look up table entries. Rx Encap Packets - The number of packets received at the encap ingress side Tx Encap Packets - The number of packets transmitted at the encap egress side Haleplidis, et al. Expires May 7, 2020 [Page 25] Internet-Draft ForCES-based BNG November 2019 Rx Encap Bytes - The number of bytes received at the encap ingress side Tx Encap Bytes - The number of bytes transmitted at the encap egress side Rx Decap Packets - The number of packets received at the decap ingress side Tx Decap Packets - The number of packets transmitted at the decap egress side Rx Decap Bytes - The number of bytes received at the decap ingress side Tx Decap Bytes - The number of bytes transmitted at the decap egress side 6.3.3. Capabilities This LFB does not have a list of capabilities. 6.3.4. Events This LFB has four events specified: Subscriber Changed - Existing PPPoE subscriber information has been changed. Subscriber deleted - This event will trigger when an existing PPPoE subscriber information has been deleted. Subscriber created - This event will trigger when a new PPPoE subscriber information has been created. Stats changed - This event will trigger periodically when stats change. It is important to properly configure the event parameters (hysteresis, interval) to avoid generation of multiple event notifications 6.4. IPv4 Routing LFB The model of IPv4 Routing LFB is responsible for selecting the next hop for upstream and downstream traffic and then to generate the correct MAC address to be inserted into the destination MAC address and the ifindex of the output port so that the packet can be send out of the BNG. Haleplidis, et al. Expires May 7, 2020 [Page 26] Internet-Draft ForCES-based BNG November 2019 6.4.1. Data Handling This LFB is used for packets sent from the Subscriber to the Network and back to locate the next hop and select the output port. IPv4 packets enter this LFB via the InPort, alongside the Subscriber Index as metadata. The IPv4 Routing LFB performs a lookup using the destination IP address on the IPv4Routing table. Once an entry has been found, the packet is checked for MTU and the next hop index is found. The next hop index is used to locate the correct enty in the IPv4NextHopTable. Once the entry has been found, the IPv4 Routing LFB decrements the TTL and populates the destination MAC address and sends the packet to the Port LFB with the ifindex metadata specifying which output port is going to be used via the NormalOut port. If an error occurs in the checksum, or TTL, packets are dropped and exit the LFB via the ExceptionOut port. 6.4.2. Components This LFB has two components, the first is the IPv4Routing Table which is the table for the IPv4 Longest Prefix Match and the second is the IPv4NextHopTable which contains information required for the next hop. Both components are tables. Each entry in the IPv4Routing table contains the following: Subscriber ID - The subscriber identifier. IPv4 Address - The destination IPv4 address which is used to look up table entries. Prefix Length - The prefix length Hop Selector - Index for the Next Hop Table to lookup the Next hop information. Each entry in the IPv4NextHopTable table contains the following: OutIfIndex - This is the interface index out of which this packet should be sent. MTU - The MTU of the outgoing port. Next Hop IP Address - The next hop IPv4 Address Next Hop MAC Address - The next hop MAC Address. Haleplidis, et al. Expires May 7, 2020 [Page 27] Internet-Draft ForCES-based BNG November 2019 6.4.3. Capabilities This LFB does not have a list of capabilities. 6.4.4. Events This LFB does not have a list of events. 6.5. Policer LFB The Policer LFB is responsible for maintaining the QoS requirements for a specific user based on his SLA either for upstream or for downstream traffic. Currently only four characteristics have been defined. The four characteristics are the Committed Information Rate, the Peak Information Rate, the Committed Burst Size and the Peak Burst Size. This LFB can be further augmented with more QoS parameters. 6.5.1. Data Handling For upstream this LFB receives IPv4 packets and Subscriber ID as metadata at the InUpstreamPort and based on the QoS parameters for that specific Subscriber, manipulates the packets to maintain the agreed upon SLA. Output packets are sent out via the OutUpstreamPort alongside the metadata, Subscriber ID. Similarly for downstream traffic, this LFB receives IPv4 packets and Subscriber ID as metadata at the InDownstreamPort and based on the QoS parameters for that specific Subscriber, manipulates the packets to maintain the agreed upon SLA. Output packets are sent out via the OutDownstreamPort alongside the metadata, Subscriber ID. 6.5.2. Components This LFB has been defined with two components, one for upstream and one for downstream traffic named PoliceUpstream and PoliceDownstream respectively. Both components are tables. Each entry in each table contains the four QoS parameters and the Subscriber ID. Each table entry is of type PolicerTableEntry. The PolicerTableEntry type contains the following configurable parameters: SubscriberID - A uint32 value to identify the Subscriber CIR - a uint32 value to represent the Committed Information Rate in kilobits per second. Haleplidis, et al. Expires May 7, 2020 [Page 28] Internet-Draft ForCES-based BNG November 2019 PIR - a uint32 value to represent the Peak Information Rate in kilobits per second. CBS - a uint32 value to represent the Committed Burst Size in bytes. PBS - a uint32 value to represent the Peak Burst Size in bytes. 6.5.3. Capabilities This LFB does not have a list of capabilities. 6.5.4. Events This LFB does not have a list of events. 7. BNG ForCES XML model In this section we provide ForCES based XML models for the LFBs in the BNG ForCES model Arbitrary Any kind of packet EthernetFrame An ethernet frame IPv4Packet An IPv4 packet operstates The possible operational states of a port link (RFC 2863) uchar Haleplidis, et al. Expires May 7, 2020 [Page 29] Internet-Draft ForCES-based BNG November 2019 OS_UNKNOWN Unknown value OS_NOTPRESENT The link is not present OS_DOWN The link is operationally down OS_LOWERLAYERDOWN The link of the lower port is down OS_TESTING The Link is undergoing some testing OS_DORMANT Link is in the dormant state OS_UP The Link is operationally up adminstates The possible administrative states of a port link (RFC 2863) uchar AS_DOWN The link is operationally down AS_LOWERLAYERDOWN The link of the lower port is down Haleplidis, et al. Expires May 7, 2020 [Page 30] Internet-Draft ForCES-based BNG November 2019 AS_DORMANT Link is in the dormant state AS_UP The Link is operationally up devstats Port stats rx_packets Total packets received uint64 tx_packets Total packets transmitted uint64 rx_bytes Total bytes received uint64 tx_bytes Total bytes transmitted uint64 rx_errors Total packet receive errors uint64 tx_errors Total packet transmit errors uint64 rx_dropped Haleplidis, et al. Expires May 7, 2020 [Page 31] Internet-Draft ForCES-based BNG November 2019 Total packet received and dropped. Typically because no space uint64 tx_dropped Total packet transmit dropped Typically because no space uint64 multicast Total multicast packets received uint64 tx_collisions Total transmit packet collisions on the link uint64 rx_length_errors rx errors because of length mismatch uint64 rx_over_errors rx errors because of buffer overflows uint64 rx_crc_errors rx errors because of crc errors uint64 rx_frame_errors rx errors because of frame alignment error uint64 Haleplidis, et al. Expires May 7, 2020 [Page 32] Internet-Draft ForCES-based BNG November 2019 rx_fifo_errors rx errors because of fifo overruns uint64 rx_missed_errors rx errors because of missed packets uint64 tx_aborted_errors tx errors because of tx abort uint64 tx_carrier_errors tx errors because of carrier problems uint64 tx_fifo_errors tx errors because of fifo problems uint64 tx_heartbeat_errors tx errors because of heartbeat problems uint64 tx_window_errors tx errors because of windowing problems uint64 rx_compressed Total rx compressed packets uint64 Haleplidis, et al. Expires May 7, 2020 [Page 33] Internet-Draft ForCES-based BNG November 2019 tx_compressed Total tx compressed packets uint64 PortInfo Describing the Port Details name The name of the port string[16] ifindex The ifindex of the port uint32 L2Address The MAC address byte[6] mtu The Maximum transmit unit for this port uint32 flags flags for config and operational state. On the FE CE direction, these flags depend on flags mask to point to which flags to change uint32 flagsmask Haleplidis, et al. Expires May 7, 2020 [Page 34] Internet-Draft ForCES-based BNG November 2019 Mask for flags for config and operational state In config direction, a bit turned on indicates that the FE is to set the corresponding flags to value specified uint32 stats The 64-bit port stats devstats operstate The Link operational state of the port operstates operstate The Link operational state of the port adminstates promiscuity The port promiscuity uint32 ethaddrs_key Ethernet address key structure eth_dst Destination Ethernet address byte[6] eth_dst_mask Destination Ethernet address mask Haleplidis, et al. Expires May 7, 2020 [Page 35] Internet-Draft ForCES-based BNG November 2019 byte[6] eth_src Source Ethernet address byte[6] eth_src_mask Source Ethernet address mask byte[6] inaddr_key IPv4 Address key structure src IP Source address (BE) octetstring[4] src_mask IP Source address mask (BE) octetstring[4] dst IP Destination address (BE) octetstring[4] dst_mask IP Destination address mask (BE) octetstring[4] Haleplidis, et al. Expires May 7, 2020 [Page 36] Internet-Draft ForCES-based BNG November 2019 PPPoE_control_key PPPoE control key structure PPPoEControl PPPoE Control Traffic. Default 0x8863 uint16 PPPControl PPP Control Protocol Traffic uint16 PPPoE_subscriber_key PPPoE control key structure PPPSessionID Session ID uint16 SubMACAddress Session ID octetstring[6] keyinfo Describes the BNG classifier key ip_proto Transport protocols: TCP, UDP, SCTP, ICMP, ICMPV6 uchar Haleplidis, et al. Expires May 7, 2020 [Page 37] Internet-Draft ForCES-based BNG November 2019 IPPROTO_ICMP IPPROTO_TCP IPPROTO_UDP IPPROTO_SCTP IPPROTO_ICMPV6 eth Ethernet header key ethaddrs_key ip IP header key inaddr_key PPPControl PPPoE control headers PPPoE_control_key PPPSubscriberTraffic_key PPPoE data headers PPPoE_subscriber_key Haleplidis, et al. Expires May 7, 2020 [Page 38] Internet-Draft ForCES-based BNG November 2019 filteractinfo Basic filter action row entry factype Action type name string[16] faction Action uchar Drop Drop packet ForwardPacket Forward packet Redirect Redirect packet to controller ClassifierFilterInfo Basic filter row entry fname Filter type name string[16] actions The actions graph filteractinfo Haleplidis, et al. Expires May 7, 2020 [Page 39] Internet-Draft ForCES-based BNG November 2019 keys Match filter keys keyinfo PPPoETableEntry PPPoE Table Entry SubscriberID Subscriber Identifier uint32 PPPSessionID Session ID uint16 SubscriberMACAddress MAC Address octetstring[6] LocalMACAddress Local MAC Address octetstring[6] MSS Maximum Segment Size uint16 MRU Maximum Receive Unit uint16 Haleplidis, et al. Expires May 7, 2020 [Page 40] Internet-Draft ForCES-based BNG November 2019 MagicNumber PPP magic number uint32 PeerMagicNumber Peer PPP magic number uint32 SubcriberStats Subscriber Statistics SubscriberID ID of the subscriber uint32 rx_encap_packets Total packets received at the encap side uint64 tx_encap_packets Total packets transmitted at the encap side uint64 rx_encap_bytes Total bytes received at the encap side uint64 tx_encap_bytes Total bytes transmitted at the encap side uint64 rx_decap_packets Total packets received at the encap side uint64 Haleplidis, et al. Expires May 7, 2020 [Page 41] Internet-Draft ForCES-based BNG November 2019 tx_decap_packets Total packets transmitted at the encap side uint64 rx_decap_bytes Total bytes received at the encap side uint64 tx_decap_bytes Total bytes transmitted at the encap side uint64 SubscriberRoutingTableEntry A routing table entry SubscriberID Subscriber Identifier. Has been generated upstream uint32 IPv4Address The destination IPv4 address octetstring[4] Prefixlen The prefix length uchar HopSelector The HopSelector produced by the prefix matching LFB, which will be used as an array index to find next-hop Haleplidis, et al. Expires May 7, 2020 [Page 42] Internet-Draft ForCES-based BNG November 2019 information. uint32 IPv4NextHopInfoType Data type for entry of IPv4 next-hop information table in IPv4NextHop LFB. The table uses a hop selector received from upstream LFB as a search key to look up index of the table to find the next-hop information. OutIfiIndex The interface index of the port that is to pass onto downstream LFB, indicating what port this packet should be sent out from. uint32 MTU Maximum Transmission Unit for outgoing port uint32 NextHopIPAddr The next-hop IPv4 address octetstring[4] NextHopMACAddr The next-hop MAC address octetstring[6] PolicerTableEntry A routing table entry SubscriberID Haleplidis, et al. Expires May 7, 2020 [Page 43] Internet-Draft ForCES-based BNG November 2019 Subscriber Identifier. Has been generated upstream uint32 CIR Committed Information Rate uint32 PIR Peak Information Rate uint32 CBS Committed Burst Size uint32 PBS Peak Burst Size uint32 SubID The ID of the subscriber 1001 uint32 OutIfIndex Interface Index to output packets 1002 uint32 Port A Port LFB 1.0 Haleplidis, et al. Expires May 7, 2020 [Page 44] Internet-Draft ForCES-based BNG November 2019 IngressInPort Ingress port from outside the BNG to be sent inside Arbitraty EgressInPort Egress port from within the BNG to be sent outside Arbitraty OutIfIndex IngressOutPort Ingress port to send packets within the BNG Arbitrary EgressOutPort Egress port to send packets out from the BNG Arbitrary ports Haleplidis, et al. Expires May 7, 2020 [Page 45] Internet-Draft ForCES-based BNG November 2019 the table of all ports PortInfo PortChanged An existing port has been updated. When the change occurs we report the table row that has changed including its contents + index (port ifindex). ports ports _pifindex_ PortDeleted An existing port has been deleted. When the change occurs we report the table row that has changed including its contents + index (port ifindex). ports ports _pifindex_ PortCreated A new port has been created. When the change occurs we report the table row that has changed including its Haleplidis, et al. Expires May 7, 2020 [Page 46] Internet-Draft ForCES-based BNG November 2019 contents + index (port ifindex). ports ports _pifindex_ PortStatsChanged Event used to advertise synchronously port stats. The ForCES eventInterval property is useful for specifying the synchronous interval. ports ports _pifindex_ Classifier A Classifier LFB. Classifies frames 1.0 InPort Input for the Classifier. Input could be from Port or tunneling infrastructure Arbitrary Haleplidis, et al. Expires May 7, 2020 [Page 47] Internet-Draft ForCES-based BNG November 2019 ControlOut Redirects packet towards the control plane. Arbitrary EthernetOut Port to send Ethenet frames EthernetFrame SubID IPv4Out Port to send IPv4 packets IPv4Packet SubID Filters The table of filters ClassifierFilterInfo Haleplidis, et al. Expires May 7, 2020 [Page 48] Internet-Draft ForCES-based BNG November 2019 FilterChanged A Filter instance has been updated. When the change occurs we report the table row that has changed including its contents + index. Filters Filters _findex_ FilterDeleted An existing Filter has been deleted. When the change occurs we report the table row that has changed including its contents + index. Filters Filters _findex_ FilterCreated A new filter has been created. When the change occurs we report the table row that has changed including its contents + index. Filters Haleplidis, et al. Expires May 7, 2020 [Page 49] Internet-Draft ForCES-based BNG November 2019 Filters _findex_ PPPoE PPPoE LFB to encap and decap packets. 1.0 EncapIn A port to encapsulate an IP packet IPv4Packet SubID OutIfIndex DecapIn A port to decapsulate a PPPoE packet EthernetFrame SubID EncapOut After Encaping an IPv4 Packet create an Ethernet frame EthernetFrame Haleplidis, et al. Expires May 7, 2020 [Page 50] Internet-Draft ForCES-based BNG November 2019 DecapOut Generates IPv4 packets IPv4Packet SubID PPPoEInfo Table with PPPoE Subscriber Information PPPoETableEntry Stats Table with statistics for Encap and Decap packets per subscriber SubcriberStats SubChanged An existing PPPoE Subscriber has been updated. When the change occurs we report the table row that has changed including its contents + subscriberID. PPPoEInfo PPPoEInfo _SubscriberID_ Haleplidis, et al. Expires May 7, 2020 [Page 51] Internet-Draft ForCES-based BNG November 2019 SubDeleted An existing PPPoE Subscriber has been deleted. When the change occurs we report the table row that has changed including its contents + subscriberID. PPPoEInfo PPPoEInfo _SubscriberID_ SubCreated A new PPPoE Subscriber has been created. When the change occurs we report the table row that has changed including its contents + subscriberID. PPPoEInfo PPPoEInfo _SubscriberID_ StatsChanged Event used to advertise synchronously encap stats. The ForCES eventInterval property is useful for specifying the synchronous interval. Stats Haleplidis, et al. Expires May 7, 2020 [Page 52] Internet-Draft ForCES-based BNG November 2019 Stats _SubscriberID_ IPv4Routing IPv4 Routing LFB 1.0 InPort Input port for packets IPv4Packet SubID NormalOut Output port for packets IPv4Packet SubID OutIfIndex ExceptionOut Port for errors IPv4Packet Haleplidis, et al. Expires May 7, 2020 [Page 53] Internet-Draft ForCES-based BNG November 2019 IPv4RoutingTable A table for IPv4 Longest Prefix Match. The destination IPv4 address of every input packet is used as a search key to look up the table to find out a next-hop selector. SubscriberRoutingTableEntry IPv4NextHopTable The IPv4NextHopTable component. A HopSelector is used to match the table index to find out a row that contains the next-hop information result. IPv4NextHopInfoType Policer Policer LFB 1.0 InUpstreamPort Input port for the Policer LFB for upstream traffic IPv4Packet SubID Haleplidis, et al. Expires May 7, 2020 [Page 54] Internet-Draft ForCES-based BNG November 2019 InDownstreamPort Input port for the Policer LFB for downstream traffic IPv4Packet SubID OutUpstreamPort Output port for the Policer LFB for upstream traffic IPv4Packet SubID OutDownstreamPort Output port for the Policer LFB for downstream traffic IPv4Packet SubID UpstreamPolicy Policy entries for upstream traffic Haleplidis, et al. Expires May 7, 2020 [Page 55] Internet-Draft ForCES-based BNG November 2019 BandwidthTableEntry DownstreamPolicy Policy entries for downstream traffic PolicerTableEntry Figure 9: BNG XML model 8. Acknowledgements The activities of Evangelos Haleplidis have been carried out with funding provided via the StandICT.eu initiative, funded with Grant Agreement no. 780439 under the European Commission's Horizon 2020 Programme. 9. IANA Considerations TBD 10. Security Considerations TBD 11. References 11.1. Normative References [I-D.haleplidis-bcause-forces-gap-analysis] Haleplidis, E. and J. Salim, "ForCES architecture CUSP applicability", draft-haleplidis-bcause-forces-gap- analysis-00 (work in progress), April 2019. [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-23 (work in progress), September 2019. Haleplidis, et al. Expires May 7, 2020 [Page 56] Internet-Draft ForCES-based BNG November 2019 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 1999, . [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, . [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, DOI 10.17487/RFC5810, March 2010, . [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol", RFC 5811, DOI 10.17487/RFC5811, March 2010, . [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, DOI 10.17487/RFC5812, March 2010, . [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, "High Availability within a Forwarding and Control Element Separation (ForCES) Network Element", RFC 7121, DOI 10.17487/RFC7121, February 2014, . [TR-101] Broadband Forum, "TR-101 - Migration to Ethernet-Based Broadband Aggregation", 2011, . 11.2. Informative References [media1] "Forces-vzn", , 06 2016, . [media2] "Forces-vzn2", , 06 2016, . Haleplidis, et al. Expires May 7, 2020 [Page 57] Internet-Draft ForCES-based BNG November 2019 [media3] "Forces-Large-Scale-Kubernetes", , 10 2019, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library", RFC 6956, DOI 10.17487/RFC6956, June 2013, . Authors' Addresses Evangelos Haleplidis M. Aleksandrou 29B Paiania, Athens 19002 Greece Email: ehalep@gmail.com Jamal Hadi Salim Mojatatu Networks Suite 200, 15 Fitzgerald Road Ottawa, Ontario K2H 9G1 Canada Email: hadi@mojatatu.com Jae Won Chung Viasat 6155 El Camino Real Carlsbad 92009 USA Email: JaeWon.Chung@viasat.com Haleplidis, et al. Expires May 7, 2020 [Page 58]