Internet DRAFT - draft-haleplidis-forces-bng
draft-haleplidis-forces-bng
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:
<Command> <Resource path> [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
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="vbng">
<frameDefs>
<frameDef>
<name>Arbitrary</name>
<synopsis>Any kind of packet</synopsis>
</frameDef>
<frameDef>
<name>EthernetFrame</name>
<synopsis>An ethernet frame</synopsis>
</frameDef>
<frameDef>
<name>IPv4Packet</name>
<synopsis>An IPv4 packet</synopsis>
</frameDef>
</frameDefs>
<dataTypeDefs>
<!-- For Port LFB -->
<dataTypeDef>
<name>operstates</name>
<synopsis>
The possible operational states of a port link (RFC 2863)
</synopsis>
<atomic>
<baseType>uchar</baseType>
Haleplidis, et al. Expires May 7, 2020 [Page 29]
Internet-Draft ForCES-based BNG November 2019
<specialValues>
<specialValue value="0">
<name>OS_UNKNOWN</name>
<synopsis>Unknown value</synopsis>
</specialValue>
<specialValue value="1">
<name>OS_NOTPRESENT</name>
<synopsis>The link is not present</synopsis>
</specialValue>
<specialValue value="2">
<name>OS_DOWN</name>
<synopsis>The link is operationally down</synopsis>
</specialValue>
<specialValue value="3">
<name>OS_LOWERLAYERDOWN</name>
<synopsis>The link of the lower port is down</synopsis>
</specialValue>
<specialValue value="4">
<name>OS_TESTING</name>
<synopsis>The Link is undergoing some testing</synopsis>
</specialValue>
<specialValue value="5">
<name>OS_DORMANT</name>
<synopsis>Link is in the dormant state</synopsis>
</specialValue>
<specialValue value="6">
<name>OS_UP</name>
<synopsis>The Link is operationally up</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>adminstates</name>
<synopsis>
The possible administrative states of a port link (RFC 2863)
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="1">
<name>AS_DOWN</name>
<synopsis>The link is operationally down</synopsis>
</specialValue>
<specialValue value="2">
<name>AS_LOWERLAYERDOWN</name>
<synopsis>The link of the lower port is down</synopsis>
</specialValue>
Haleplidis, et al. Expires May 7, 2020 [Page 30]
Internet-Draft ForCES-based BNG November 2019
<specialValue value="3">
<name>AS_DORMANT</name>
<synopsis>Link is in the dormant state</synopsis>
</specialValue>
<specialValue value="4">
<name>AS_UP</name>
<synopsis>The Link is operationally up</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>devstats</name>
<synopsis>Port stats</synopsis>
<struct>
<component componentID="1">
<name>rx_packets</name>
<synopsis>Total packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>tx_packets</name>
<synopsis>Total packets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>rx_bytes</name>
<synopsis>Total bytes received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>tx_bytes</name>
<synopsis>Total bytes transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="5">
<name>rx_errors</name>
<synopsis>Total packet receive errors</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="6">
<name>tx_errors</name>
<synopsis>Total packet transmit errors</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="7">
<name>rx_dropped</name>
<synopsis>
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
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="8">
<name>tx_dropped</name>
<synopsis>
Total packet transmit dropped Typically because no space
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="9">
<name>multicast</name>
<synopsis>Total multicast packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="10">
<name>tx_collisions</name>
<synopsis>Total transmit packet collisions on the
link</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="11">
<name>rx_length_errors</name>
<synopsis>rx errors because of length mismatch</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="12">
<name>rx_over_errors</name>
<synopsis>rx errors because of buffer overflows</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="13">
<name>rx_crc_errors</name>
<synopsis>rx errors because of crc errors</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="14">
<name>rx_frame_errors</name>
<synopsis>rx errors because of frame alignment
error</synopsis>
<optional/>
<typeRef>uint64</typeRef>
Haleplidis, et al. Expires May 7, 2020 [Page 32]
Internet-Draft ForCES-based BNG November 2019
</component>
<component componentID="15">
<name>rx_fifo_errors</name>
<synopsis>rx errors because of fifo overruns</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="16">
<name>rx_missed_errors</name>
<synopsis>rx errors because of missed packets</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="17">
<name>tx_aborted_errors</name>
<synopsis>tx errors because of tx abort</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="18">
<name>tx_carrier_errors</name>
<synopsis>tx errors because of carrier problems</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="19">
<name>tx_fifo_errors</name>
<synopsis>tx errors because of fifo problems</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="20">
<name>tx_heartbeat_errors</name>
<synopsis>tx errors because of heartbeat problems</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="21">
<name>tx_window_errors</name>
<synopsis>tx errors because of windowing problems</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
<component componentID="22">
<name>rx_compressed</name>
<synopsis>Total rx compressed packets</synopsis>
<optional/>
<typeRef>uint64</typeRef>
Haleplidis, et al. Expires May 7, 2020 [Page 33]
Internet-Draft ForCES-based BNG November 2019
</component>
<component componentID="23">
<name>tx_compressed</name>
<synopsis>Total tx compressed packets</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>PortInfo</name>
<synopsis>Describing the Port Details</synopsis>
<struct>
<component componentID="1">
<name>name</name>
<synopsis>The name of the port</synopsis>
<optional/>
<typeRef>string[16]</typeRef>
</component>
<component componentID="2">
<name>ifindex</name>
<synopsis>The ifindex of the port</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>L2Address</name>
<synopsis>The MAC address</synopsis>
<optional/>
<typeRef>byte[6]</typeRef>
</component>
<component componentID="4">
<name>mtu</name>
<synopsis>The Maximum transmit unit for this port</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>flags</name>
<synopsis>
flags for config and operational state. On the FE CE
direction, these flags depend on flags mask to point to
which flags to change
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="6">
<name>flagsmask</name>
Haleplidis, et al. Expires May 7, 2020 [Page 34]
Internet-Draft ForCES-based BNG November 2019
<synopsis>
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
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="7">
<name>stats</name>
<synopsis>The 64-bit port stats</synopsis>
<optional/>
<typeRef>devstats</typeRef>
</component>
<component componentID="8">
<name>operstate</name>
<synopsis>The Link operational state of the port</synopsis>
<optional/>
<typeRef>operstates</typeRef>
</component>
<component componentID="9">
<name>operstate</name>
<synopsis>The Link operational state of the port</synopsis>
<optional/>
<typeRef>adminstates</typeRef>
</component>
<component componentID="10">
<name>promiscuity</name>
<synopsis>The port promiscuity</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<!-- For Classifier -->
<dataTypeDef>
<name>ethaddrs_key</name>
<synopsis>Ethernet address key structure</synopsis>
<struct>
<component componentID="1">
<name>eth_dst</name>
<synopsis>Destination Ethernet address</synopsis>
<optional/>
<typeRef>byte[6]</typeRef>
</component>
<component componentID="2">
<name>eth_dst_mask</name>
<synopsis>Destination Ethernet address mask</synopsis>
Haleplidis, et al. Expires May 7, 2020 [Page 35]
Internet-Draft ForCES-based BNG November 2019
<optional/>
<typeRef>byte[6]</typeRef>
</component>
<component componentID="3">
<name>eth_src</name>
<synopsis>Source Ethernet address</synopsis>
<optional/>
<typeRef>byte[6]</typeRef>
</component>
<component componentID="4">
<name>eth_src_mask</name>
<synopsis>Source Ethernet address mask</synopsis>
<optional/>
<typeRef>byte[6]</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>inaddr_key</name>
<synopsis>IPv4 Address key structure</synopsis>
<struct>
<component componentID="1">
<name>src</name>
<synopsis>IP Source address (BE)</synopsis>
<optional/>
<typeRef>octetstring[4]</typeRef>
</component>
<component componentID="2">
<name>src_mask</name>
<synopsis>IP Source address mask (BE)</synopsis>
<optional/>
<typeRef>octetstring[4]</typeRef>
</component>
<component componentID="3">
<name>dst</name>
<synopsis>IP Destination address (BE)</synopsis>
<optional/>
<typeRef>octetstring[4]</typeRef>
</component>
<component componentID="4">
<name>dst_mask</name>
<synopsis>IP Destination address mask (BE)</synopsis>
<optional/>
<typeRef>octetstring[4]</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
Haleplidis, et al. Expires May 7, 2020 [Page 36]
Internet-Draft ForCES-based BNG November 2019
<name>PPPoE_control_key</name>
<synopsis>PPPoE control key structure</synopsis>
<struct>
<component componentID="1">
<name>PPPoEControl</name>
<synopsis>PPPoE Control Traffic. Default 0x8863</synopsis>
<optional/>
<typeRef>uint16</typeRef>
</component>
<component componentID="2">
<name>PPPControl</name>
<synopsis>PPP Control Protocol Traffic</synopsis>
<optional/>
<typeRef>uint16</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>PPPoE_subscriber_key</name>
<synopsis>PPPoE control key structure</synopsis>
<struct>
<component componentID="1">
<name>PPPSessionID</name>
<synopsis>Session ID</synopsis>
<optional/>
<typeRef>uint16</typeRef>
</component>
<component componentID="2">
<name>SubMACAddress</name>
<synopsis>Session ID</synopsis>
<optional/>
<typeRef>octetstring[6]</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>keyinfo</name>
<synopsis>Describes the BNG classifier key</synopsis>
<struct>
<component componentID="1">
<name>ip_proto</name>
<synopsis>Transport protocols: TCP, UDP, SCTP, ICMP,
ICMPV6</synopsis>
<optional/>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="1">
Haleplidis, et al. Expires May 7, 2020 [Page 37]
Internet-Draft ForCES-based BNG November 2019
<name>IPPROTO_ICMP</name>
<synopsis/>
</specialValue>
<specialValue value="6">
<name>IPPROTO_TCP</name>
<synopsis/>
</specialValue>
<specialValue value="17">
<name>IPPROTO_UDP</name>
<synopsis/>
</specialValue>
<specialValue value="132">
<name>IPPROTO_SCTP</name>
<synopsis/>
</specialValue>
<specialValue value="58">
<name>IPPROTO_ICMPV6</name>
<synopsis/>
</specialValue>
</specialValues>
</atomic>
</component>
<component componentID="2">
<name>eth</name>
<synopsis>Ethernet header key</synopsis>
<optional/>
<typeRef>ethaddrs_key</typeRef>
</component>
<component componentID="3">
<name>ip</name>
<synopsis>IP header key</synopsis>
<optional/>
<typeRef>inaddr_key</typeRef>
</component>
<component componentID="4">
<name>PPPControl</name>
<synopsis>PPPoE control headers</synopsis>
<optional/>
<typeRef>PPPoE_control_key</typeRef>
</component>
<component componentID="5">
<name>PPPSubscriberTraffic_key</name>
<synopsis>PPPoE data headers</synopsis>
<optional/>
<typeRef>PPPoE_subscriber_key</typeRef>
</component>
</struct>
</dataTypeDef>
Haleplidis, et al. Expires May 7, 2020 [Page 38]
Internet-Draft ForCES-based BNG November 2019
<dataTypeDef>
<name>filteractinfo</name>
<synopsis>Basic filter action row entry</synopsis>
<struct>
<component componentID="1">
<name>factype</name>
<synopsis>Action type name</synopsis>
<typeRef>string[16]</typeRef>
</component>
<component componentID="2">
<name>faction</name>
<synopsis>Action</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>Drop</name>
<synopsis>Drop packet</synopsis>
</specialValue>
<specialValue value="1">
<name>ForwardPacket</name>
<synopsis>Forward packet</synopsis>
</specialValue>
<specialValue value="2">
<name>Redirect</name>
<synopsis>Redirect packet to controller</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>ClassifierFilterInfo</name>
<synopsis>Basic filter row entry</synopsis>
<struct>
<component componentID="1">
<name>fname</name>
<synopsis>Filter type name</synopsis>
<typeRef>string[16]</typeRef>
</component>
<component componentID="2">
<name>actions</name>
<synopsis>The actions graph</synopsis>
<array type="variable-size">
<typeRef>filteractinfo</typeRef>
</array>
</component>
Haleplidis, et al. Expires May 7, 2020 [Page 39]
Internet-Draft ForCES-based BNG November 2019
<component componentID="3">
<name>keys</name>
<synopsis>Match filter keys</synopsis>
<optional/>
<array type="variable-size">
<typeRef>keyinfo</typeRef>
</array>
</component>
</struct>
</dataTypeDef>
<!-- For PPPoE LFB -->
<dataTypeDef>
<name>PPPoETableEntry</name>
<synopsis>PPPoE Table Entry</synopsis>
<struct>
<component componentID="1">
<name>SubscriberID</name>
<synopsis>Subscriber Identifier</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>PPPSessionID</name>
<synopsis>Session ID</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="3">
<name>SubscriberMACAddress</name>
<synopsis>MAC Address</synopsis>
<typeRef>octetstring[6]</typeRef>
</component>
<component componentID="4">
<name>LocalMACAddress</name>
<synopsis>Local MAC Address</synopsis>
<typeRef>octetstring[6]</typeRef>
</component>
<component componentID="5">
<name>MSS</name>
<synopsis>Maximum Segment Size</synopsis>
<optional/>
<typeRef>uint16</typeRef>
</component>
<component componentID="6">
<name>MRU</name>
<synopsis>Maximum Receive Unit</synopsis>
<optional/>
<typeRef>uint16</typeRef>
</component>
<component componentID="7">
Haleplidis, et al. Expires May 7, 2020 [Page 40]
Internet-Draft ForCES-based BNG November 2019
<name>MagicNumber</name>
<synopsis>PPP magic number</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="8">
<name>PeerMagicNumber</name>
<synopsis>Peer PPP magic number</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>SubcriberStats</name>
<synopsis>Subscriber Statistics</synopsis>
<struct>
<component componentID="1">
<name>SubscriberID</name>
<synopsis>ID of the subscriber</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>rx_encap_packets</name>
<synopsis>Total packets received at the encap side</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>tx_encap_packets</name>
<synopsis>Total packets transmitted at the encap side</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>rx_encap_bytes</name>
<synopsis>Total bytes received at the encap side</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="5">
<name>tx_encap_bytes</name>
<synopsis>Total bytes transmitted at the encap side</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="6">
<name>rx_decap_packets</name>
<synopsis>Total packets received at the encap side</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="7">
Haleplidis, et al. Expires May 7, 2020 [Page 41]
Internet-Draft ForCES-based BNG November 2019
<name>tx_decap_packets</name>
<synopsis>Total packets transmitted at the encap side</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="8">
<name>rx_decap_bytes</name>
<synopsis>Total bytes received at the encap side</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="9">
<name>tx_decap_bytes</name>
<synopsis>Total bytes transmitted at the encap side</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<!-- For IPv4 Routing LFB -->
<dataTypeDef>
<name>SubscriberRoutingTableEntry</name>
<synopsis>A routing table entry</synopsis>
<struct>
<component componentID="1">
<name>SubscriberID</name>
<synopsis>Subscriber Identifier. Has been generated
upstream</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>IPv4Address</name>
<synopsis>The destination IPv4 address</synopsis>
<typeRef>octetstring[4]</typeRef>
</component>
<component componentID="3">
<name>Prefixlen</name>
<synopsis>The prefix length</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="32"/>
</rangeRestriction>
</atomic>
</component>
<component componentID="4">
<name>HopSelector</name>
<synopsis>
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.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4NextHopInfoType</name>
<synopsis>
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.
</synopsis>
<struct>
<component componentID="1">
<name>OutIfiIndex</name>
<synopsis>
The interface index of the port that is to pass
onto downstream LFB, indicating what port this packet
should be sent out from.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MTU</name>
<synopsis>
Maximum Transmission Unit for outgoing port
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>NextHopIPAddr</name>
<synopsis>The next-hop IPv4 address</synopsis>
<typeRef>octetstring[4]</typeRef>
</component>
<component componentID="4">
<name>NextHopMACAddr</name>
<synopsis>The next-hop MAC address</synopsis>
<typeRef>octetstring[6]</typeRef>
</component>
</struct>
</dataTypeDef>
<!-- For PolicerLFB -->
<dataTypeDef>
<name>PolicerTableEntry</name>
<synopsis>A routing table entry</synopsis>
<struct>
<component componentID="1">
<name>SubscriberID</name>
Haleplidis, et al. Expires May 7, 2020 [Page 43]
Internet-Draft ForCES-based BNG November 2019
<synopsis>Subscriber Identifier. Has been generated
upstream</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>CIR</name>
<synopsis>Committed Information Rate</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>PIR</name>
<synopsis>Peak Information Rate </synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>CBS</name>
<synopsis>Committed Burst Size</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>PBS</name>
<synopsis>Peak Burst Size</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
</dataTypeDefs>
<metadataDefs>
<metadataDef>
<name>SubID</name>
<synopsis>The ID of the subscriber</synopsis>
<metadataID>1001</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>OutIfIndex</name>
<synopsis>Interface Index to output packets</synopsis>
<metadataID>1002</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
</metadataDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="2001">
<name>Port</name>
<synopsis>A Port LFB</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
Haleplidis, et al. Expires May 7, 2020 [Page 44]
Internet-Draft ForCES-based BNG November 2019
<name>IngressInPort</name>
<synopsis>Ingress port from outside the BNG to be
sent inside</synopsis>
<expectation>
<frameExpected>
<ref>Arbitraty</ref>
</frameExpected>
</expectation>
</inputPort>
<inputPort>
<name>EgressInPort</name>
<synopsis>Egress port from within the BNG to be
sent outside</synopsis>
<expectation>
<frameExpected>
<ref>Arbitraty</ref>
</frameExpected>
<metadataExpected>
<ref>OutIfIndex</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>IngressOutPort</name>
<synopsis>Ingress port to send packets within the
BNG</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>EgressOutPort</name>
<synopsis>Egress port to send packets out from the
BNG</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>ports</name>
Haleplidis, et al. Expires May 7, 2020 [Page 45]
Internet-Draft ForCES-based BNG November 2019
<synopsis>the table of all ports</synopsis>
<array type="variable-size">
<typeRef>PortInfo</typeRef>
</array>
</component>
</components>
<events baseID="161">
<event eventID="1">
<name>PortChanged</name>
<synopsis>
An existing port has been updated.
When the change occurs we report the table row that has
changed including its contents + index (port ifindex).
</synopsis>
<eventTarget>
<eventField>ports</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>ports</eventField>
<eventSubscript>_pifindex_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>PortDeleted</name>
<synopsis>
An existing port has been deleted.
When the change occurs we report the table row that
has changed including its contents + index (port ifindex).
</synopsis>
<eventTarget>
<eventField>ports</eventField>
</eventTarget>
<eventDeleted/>
<eventReports>
<eventReport>
<eventField>ports</eventField>
<eventSubscript>_pifindex_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>PortCreated</name>
<synopsis>
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).
</synopsis>
<eventTarget>
<eventField>ports</eventField>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>ports</eventField>
<eventSubscript>_pifindex_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="4">
<name>PortStatsChanged</name>
<synopsis>
Event used to advertise synchronously port stats. The
ForCES eventInterval property is useful for specifying the
synchronous interval.
</synopsis>
<eventTarget>
<eventField>ports</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>ports</eventField>
<eventSubscript>_pifindex_</eventSubscript>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
<LFBClassDef LFBClassID="2002">
<name>Classifier</name>
<synopsis>A Classifier LFB. Classifies frames</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>InPort</name>
<synopsis>Input for the Classifier. Input could be from
Port or tunneling infrastructure</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
Haleplidis, et al. Expires May 7, 2020 [Page 47]
Internet-Draft ForCES-based BNG November 2019
</inputPorts>
<outputPorts>
<outputPort>
<name>ControlOut</name>
<synopsis>Redirects packet towards the control plane.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>EthernetOut</name>
<synopsis>Port to send Ethenet frames</synopsis>
<product>
<frameProduced>
<ref>EthernetFrame</ref>
</frameProduced>
<metadataProduced>
<ref>SubID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>IPv4Out</name>
<synopsis>Port to send IPv4 packets</synopsis>
<product>
<frameProduced>
<ref>IPv4Packet</ref>
</frameProduced>
<metadataProduced>
<ref>SubID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>Filters</name>
<synopsis>The table of filters</synopsis>
<array type="variable-size">
<typeRef>ClassifierFilterInfo</typeRef>
</array>
</component>
</components>
<events baseID="61">
<event eventID="1">
Haleplidis, et al. Expires May 7, 2020 [Page 48]
Internet-Draft ForCES-based BNG November 2019
<name>FilterChanged</name>
<synopsis>
A Filter instance has been updated. When the change occurs
we report the table row that has changed including
its contents + index.
</synopsis>
<eventTarget>
<eventField>Filters</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>Filters</eventField>
<eventSubscript>_findex_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>FilterDeleted</name>
<synopsis>
An existing Filter has been deleted. When the change
occurs we report the table row that has changed including
its contents + index.
</synopsis>
<eventTarget>
<eventField>Filters</eventField>
</eventTarget>
<eventDeleted/>
<eventReports>
<eventReport>
<eventField>Filters</eventField>
<eventSubscript>_findex_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>FilterCreated</name>
<synopsis>
A new filter has been created. When the change occurs
we report the table row that has changed including
its contents + index.
</synopsis>
<eventTarget>
<eventField>Filters</eventField>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
Haleplidis, et al. Expires May 7, 2020 [Page 49]
Internet-Draft ForCES-based BNG November 2019
<eventField>Filters</eventField>
<eventSubscript>_findex_</eventSubscript>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
<LFBClassDef LFBClassID="2003">
<name>PPPoE</name>
<synopsis>PPPoE LFB to encap and decap packets.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>EncapIn</name>
<synopsis>A port to encapsulate an IP packet</synopsis>
<expectation>
<frameExpected>
<ref>IPv4Packet</ref>
</frameExpected>
<metadataExpected>
<ref>SubID</ref>
<ref>OutIfIndex</ref>
</metadataExpected>
</expectation>
</inputPort>
<inputPort>
<name>DecapIn</name>
<synopsis>A port to decapsulate a PPPoE packet</synopsis>
<expectation>
<frameExpected>
<ref>EthernetFrame</ref>
</frameExpected>
<metadataExpected>
<ref>SubID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>EncapOut</name>
<synopsis>After Encaping an IPv4 Packet create an Ethernet
frame</synopsis>
<product>
<frameProduced>
<ref>EthernetFrame</ref>
</frameProduced>
</product>
Haleplidis, et al. Expires May 7, 2020 [Page 50]
Internet-Draft ForCES-based BNG November 2019
</outputPort>
<outputPort>
<name>DecapOut</name>
<synopsis>Generates IPv4 packets</synopsis>
<product>
<frameProduced>
<ref>IPv4Packet</ref>
</frameProduced>
<metadataProduced>
<ref>SubID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>PPPoEInfo</name>
<synopsis>Table with PPPoE Subscriber Information</synopsis>
<array>
<typeRef>PPPoETableEntry</typeRef>
</array>
</component>
<component componentID="2" access="read-only">
<name>Stats</name>
<synopsis>Table with statistics for Encap and Decap
packets per subscriber</synopsis>
<array>
<typeRef>SubcriberStats</typeRef>
</array>
</component>
</components>
<events baseID="161">
<event eventID="1">
<name>SubChanged</name>
<synopsis>
An existing PPPoE Subscriber has been updated.
When the change occurs we report the table row that has
changed including its contents + subscriberID.
</synopsis>
<eventTarget>
<eventField>PPPoEInfo</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>PPPoEInfo</eventField>
<eventSubscript>_SubscriberID_</eventSubscript>
</eventReport>
Haleplidis, et al. Expires May 7, 2020 [Page 51]
Internet-Draft ForCES-based BNG November 2019
</eventReports>
</event>
<event eventID="2">
<name>SubDeleted</name>
<synopsis>
An existing PPPoE Subscriber has been deleted.
When the change occurs we report the table row that has
changed including its contents + subscriberID.
</synopsis>
<eventTarget>
<eventField>PPPoEInfo</eventField>
</eventTarget>
<eventDeleted/>
<eventReports>
<eventReport>
<eventField>PPPoEInfo</eventField>
<eventSubscript>_SubscriberID_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>SubCreated</name>
<synopsis>
A new PPPoE Subscriber has been created.
When the change occurs we report the table row that has
changed including its contents + subscriberID.
</synopsis>
<eventTarget>
<eventField>PPPoEInfo</eventField>
</eventTarget>
<eventCreated/>
<eventReports>
<eventReport>
<eventField>PPPoEInfo</eventField>
<eventSubscript>_SubscriberID_</eventSubscript>
</eventReport>
</eventReports>
</event>
<event eventID="4">
<name>StatsChanged</name>
<synopsis>
Event used to advertise synchronously encap stats. The
ForCES eventInterval property is useful for specifying the
synchronous interval.
</synopsis>
<eventTarget>
<eventField>Stats</eventField>
</eventTarget>
Haleplidis, et al. Expires May 7, 2020 [Page 52]
Internet-Draft ForCES-based BNG November 2019
<eventChanged/>
<eventReports>
<eventReport>
<eventField>Stats</eventField>
<eventSubscript>_SubscriberID_</eventSubscript>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
<LFBClassDef LFBClassID="2004">
<name>IPv4Routing</name>
<synopsis>IPv4 Routing LFB</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>InPort</name>
<synopsis>Input port for packets</synopsis>
<expectation>
<frameExpected>
<ref>IPv4Packet</ref>
</frameExpected>
<metadataExpected>
<ref>SubID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>NormalOut</name>
<synopsis>Output port for packets</synopsis>
<product>
<frameProduced>
<ref>IPv4Packet</ref>
</frameProduced>
<metadataProduced>
<ref>SubID</ref>
<ref>OutIfIndex</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>Port for errors</synopsis>
<product>
<frameProduced>
<ref>IPv4Packet</ref>
Haleplidis, et al. Expires May 7, 2020 [Page 53]
Internet-Draft ForCES-based BNG November 2019
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>IPv4RoutingTable</name>
<synopsis>
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.
</synopsis>
<array>
<typeRef>SubscriberRoutingTableEntry</typeRef>
</array>
</component>
<component componentID="2" access="read-write">
<name>IPv4NextHopTable</name>
<synopsis>
The IPv4NextHopTable component. A
HopSelector is used to match the table index
to find out a row that contains the next-hop
information result.
</synopsis>
<array>
<typeRef>IPv4NextHopInfoType</typeRef>
</array>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="2005">
<name>Policer</name>
<synopsis>Policer LFB</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>InUpstreamPort</name>
<synopsis>Input port for the Policer LFB for upstream
traffic</synopsis>
<expectation>
<frameExpected>
<ref>IPv4Packet</ref>
</frameExpected>
<metadataExpected>
<ref>SubID</ref>
</metadataExpected>
</expectation>
Haleplidis, et al. Expires May 7, 2020 [Page 54]
Internet-Draft ForCES-based BNG November 2019
</inputPort>
<inputPort>
<name>InDownstreamPort</name>
<synopsis>Input port for the Policer LFB for downstream
traffic</synopsis>
<expectation>
<frameExpected>
<ref>IPv4Packet</ref>
</frameExpected>
<metadataExpected>
<ref>SubID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>OutUpstreamPort</name>
<synopsis>Output port for the Policer LFB for upstream
traffic</synopsis>
<product>
<frameProduced>
<ref>IPv4Packet</ref>
</frameProduced>
<metadataProduced>
<ref>SubID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>OutDownstreamPort</name>
<synopsis>Output port for the Policer LFB for downstream
traffic</synopsis>
<product>
<frameProduced>
<ref>IPv4Packet</ref>
</frameProduced>
<metadataProduced>
<ref>SubID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>UpstreamPolicy</name>
<synopsis>Policy entries for upstream traffic</synopsis>
<array>
Haleplidis, et al. Expires May 7, 2020 [Page 55]
Internet-Draft ForCES-based BNG November 2019
<typeRef>BandwidthTableEntry</typeRef>
</array>
</component>
<component componentID="2" access="read-write">
<name>DownstreamPolicy</name>
<synopsis>Policy entries for downstream traffic</synopsis>
<array>
<typeRef>PolicerTableEntry</typeRef>
</array>
</component>
</components>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
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, <https://www.rfc-editor.org/info/rfc2516>.
[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,
<https://www.rfc-editor.org/info/rfc3746>.
[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,
<https://www.rfc-editor.org/info/rfc5810>.
[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,
<https://www.rfc-editor.org/info/rfc5811>.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model",
RFC 5812, DOI 10.17487/RFC5812, March 2010,
<https://www.rfc-editor.org/info/rfc5812>.
[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,
<https://www.rfc-editor.org/info/rfc7121>.
[TR-101] Broadband Forum, "TR-101 - Migration to Ethernet-Based
Broadband Aggregation", 2011, <https://www.broadband-
forum.org/download/TR-101_Issue-2.pdf>.
11.2. Informative References
[media1] "Forces-vzn", , 06 2016,
<https://www.sdxcentral.com/articles/news/verizon-uses-
radisys-mojatatu-sdn-nfv/2016/06/>.
[media2] "Forces-vzn2", , 06 2016,
<https://www.sdxcentral.com/articles/news/meet-mojatatu-
quiet-company-verizon-chose-sdn/2016/06/>.
Haleplidis, et al. Expires May 7, 2020 [Page 57]
Internet-Draft ForCES-based BNG November 2019
[media3] "Forces-Large-Scale-Kubernetes", , 10 2019,
<https://www.cengn.ca/mojatatu-analysis-kubernetes-
deployments/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc6956>.
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]
