draft-ietf-forces-interfelfb-00.txt   draft-ietf-forces-interfelfb-01.txt 
Internet Engineering Task Force D. Joachimpillai Internet Engineering Task Force D. Joachimpillai
Internet-Draft Verizon Internet-Draft Verizon
Intended status: Standards Track J. Hadi Salim Intended status: Standards Track J. Hadi Salim
Expires: July 8, 2015 Mojatatu Networks Expires: September 7, 2015 Mojatatu Networks
January 4, 2015 March 6, 2015
ForCES Inter-FE LFB ForCES Inter-FE LFB
draft-ietf-forces-interfelfb-00 draft-ietf-forces-interfelfb-01
Abstract Abstract
This document describes extending the ForCES LFB topology across FEs This document describes extending the ForCES LFB topology across FEs
i.e inter-FE connectivity without needing any changes to the ForCES i.e inter-FE connectivity without needing any changes to the ForCES
definitions by defining the Inter-FE LFB. The Inter-FE LFB provides specification by defining the Inter-FE LFB. The Inter-FE LFB
ability to pass data, metadata and exceptions across FEs. The provides ability to pass data, metadata and exceptions across FEs.
document describes a generic way to transport the mentioned details The document describes a generic way to transport the mentioned
but focuses on ethernet transport. details but focuses on ethernet transport.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 8, 2015. This Internet-Draft will expire on September 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Scope And Use Cases . . . . . . . . . . . . . . . . . 4 3. Problem Scope And Use Cases . . . . . . . . . . . . . . . . . 4
3.1. Basic Router . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Basic Router . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Distributing The LFB Topology . . . . . . . . . . . . 6 3.1.1. Distributing The LFB Topology . . . . . . . . . . . . 6
3.2. Arbitrary Network Function . . . . . . . . . . . . . . . . 7 3.2. Arbitrary Network Function . . . . . . . . . . . . . . . . 7
3.2.1. Distributing The Arbitrary Network Function . . . . . 8 3.2.1. Distributing The Arbitrary Network Function . . . . . 8
4. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 9 4. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Inserting The Inter-FE LFB . . . . . . . . . . . . . . . . 9 4.1. Inserting The Inter-FE LFB . . . . . . . . . . . . . . . . 9
5. Generic Inter-FE connectivity . . . . . . . . . . . . . . . . 11 5. Generic Inter-FE connectivity . . . . . . . . . . . . . . . . 11
5.1. Inter-FE Ethernet connectivity . . . . . . . . . . . . . . 13 5.1. Inter-FE Ethernet Connectivity . . . . . . . . . . . . . . 13
5.1.1. Inter-FE Ethernet Connectivity Issues . . . . . . . . 15 5.1.1. Inter-FE Ethernet Connectivity Issues . . . . . . . . 15
6. Detailed Description of the Ethernet inter-FE LFB . . . . . . 16 6. Detailed Description of the Ethernet inter-FE LFB . . . . . . 16
6.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 16
6.1.1. Egress Processing . . . . . . . . . . . . . . . . . . 17 6.1.1. Egress Processing . . . . . . . . . . . . . . . . . . 17
6.1.2. Ingress Processing . . . . . . . . . . . . . . . . . . 18 6.1.2. Ingress Processing . . . . . . . . . . . . . . . . . . 18
6.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Inter-FE LFB XML Model . . . . . . . . . . . . . . . . . . 19 6.3. Inter-FE LFB XML Model . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. IEEE Assignment Considerations . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Definitions 1.2. Definitions
skipping to change at page 3, line 50 skipping to change at page 3, line 50
2. Introduction 2. Introduction
In the ForCES architecture, a packet service can be modelled by In the ForCES architecture, a packet service can be modelled by
composing a graph of one or more LFB instances. The reader is composing a graph of one or more LFB instances. The reader is
referred to the details in the ForCES Model [RFC5812]. referred to the details in the ForCES Model [RFC5812].
The FEObject LFB capabilities in the ForCES Model [RFC5812] define The FEObject LFB capabilities in the ForCES Model [RFC5812] define
component ModifiableLFBTopology which, when advertised by the FE, component ModifiableLFBTopology which, when advertised by the FE,
implies that the advertising FE is capable of allowing creation and implies that the advertising FE is capable of allowing creation and
modification the LFB graph by the control plane. Details on how a modification of LFB graph(s) by the control plane. Details on how a
graph of LFB class instances can be created can be derived by the graph of LFB class instances can be created can be derived by the
control plane by looking at the FE's FEObject LFB class table control plane by looking at the FE's FEObject LFB class table
component SupportedLFBs. The SupportedLFBs table contains component SupportedLFBs. The SupportedLFBs table contains
information about each LFB class that the FE supports. For each LFB information about each LFB class that the FE supports. For each LFB
class supported, details are provided on how the supported LFB class class supported, details are provided on how the supported LFB class
may be connected to other LFB classes. The SupportedLFBs table may be connected to other LFB classes. The SupportedLFBs table
describes which LFB class a specified LFB class may succeed or describes which LFB class a specified LFB class may succeed or
precede in an LFB class instance topology. Each link connecting two precede in an LFB class instance topology. Each link connecting two
LFB class instances is described in the LFBLinkType dataTypeDef and LFB class instances is described in the LFBLinkType dataTypeDef and
has sufficient details to identify precisely the end points of a link has sufficient details to identify precisely the end points of a link
skipping to change at page 5, line 14 skipping to change at page 5, line 14
instead of multiple LFB class instances. instead of multiple LFB class instances.
Since the illustration is meant only as an exercise to showcase how Since the illustration is meant only as an exercise to showcase how
data and metadata are sent down or upstream on a graph of LFBs, it data and metadata are sent down or upstream on a graph of LFBs, it
abstracts out any ports in both directions and talks about a generic abstracts out any ports in both directions and talks about a generic
ingress and egress LFB. Again, for illustration purposes, the ingress and egress LFB. Again, for illustration purposes, the
diagram does not show exception or error paths. Also left out are diagram does not show exception or error paths. Also left out are
details on Reverse Path Filtering, ECMP, multicast handling etc. In details on Reverse Path Filtering, ECMP, multicast handling etc. In
other words, this is not meant to be a complete description of an other words, this is not meant to be a complete description of an
IPV4 forwarding application; for a more complete example, please IPV4 forwarding application; for a more complete example, please
refer to the LFBlib document [RFC6956] . refer to the LFBlib document [RFC6956].
The output of the ingress LFB(s) coming into the IPv4 Validator LFB The output of the ingress LFB(s) coming into the IPv4 Validator LFB
will have both the IPV4 packets and, depending on the implementation, will have both the IPV4 packets and, depending on the implementation,
a variety of ingress metadata such as offsets into the different a variety of ingress metadata such as offsets into the different
headers, any classification metadata, physical and virtual ports headers, any classification metadata, physical and virtual ports
encountered, tunnelling information etc. These metadata are lumped encountered, tunnelling information etc. These metadata are lumped
together as "ingress metadata". together as "ingress metadata".
Once the IPV4 validator vets the packet (example ensures that no Once the IPV4 validator vets the packet (example ensures that no
expired TTL etc), it feeds the packet and inherited metadata into the expired TTL etc), it feeds the packet and inherited metadata into the
skipping to change at page 7, line 35 skipping to change at page 7, line 35
| +--------+ +--------+ | | +--------+ +--------+ |
| | Egress | IPV4 packet | IPV4 | | | | Egress | IPV4 packet | IPV4 | |
| <-----+ LFB |<----------------------+NextHop | | | <-----+ LFB |<----------------------+NextHop | |
| | |{ingress + NHdetails} | LFB | | | | |{ingress + NHdetails} | LFB | |
| +--------+ metadata +--------+ | | +--------+ metadata +--------+ |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
Figure 2: Split IPV4 packet service LFB topology Figure 2: Split IPV4 packet service LFB topology
Some proprietary inter-connect (example Broadcom Higig over XAUI Some proprietary inter-connect (example Broadcom Higig over XAUI
(XXX: ref needed)) maybe exist to carry both the IPV4 packet and the [brcm-higig]) are known to exist to carry both the IPV4 packet and
related metadata between the IPV4 Unicast LFB and IPV4 NextHop LFB the related metadata between the IPV4 Unicast LFB and IPV4 NextHop
across the two FEs. LFB across the two FEs.
The purpose of the inter-FE LFB is to define standard mechanisms for The purpose of the inter-FE LFB is to define standard mechanisms for
interconnecting FEs and for that reason we are not going to touch interconnecting FEs and for that reason we are not going to touch
anymore on proprietary chip-chip interconnects other than state the anymore on proprietary chip-chip interconnects other than state the
fact they exist and that it is feasible to have translation to and fact they exist and that it is feasible to have translation to and
from proprietary approaches. The document focus is the FE-FE from proprietary approaches. The document focus is the FE-FE
interconnect where the FE could be physical or virtual and the interconnect where the FE could be physical or virtual and the
interconnecting technology runs a standard protocol such as ethernet, interconnecting technology runs a standard protocol such as ethernet,
IP or other protocols on top of IP. IP or other protocols on top of IP.
skipping to change at page 8, line 22 skipping to change at page 8, line 22
| +----------+ metadata | | metadata | | | | +----------+ metadata | | metadata | | |
| ^ +----+ | | | | ^ +----+ | | |
| | +--+--+ | | | +--+--+ |
| | | | | | | |
| | | | | |
+---------------------------------------------------|---------+ +---------------------------------------------------|---------+
V V
Figure 3: A Network Function Service Chain within one FE Figure 3: A Network Function Service Chain within one FE
The setup in Figure 3 is atypical of most packet processing boxes The setup in Figure 3 is a typical of most packet processing boxes
where we have functions like DPI, NAT, Routing, etc connected in such where we have functions like DPI, NAT, Routing, etc connected in such
a topology to deliver a packet processing service to flows. a topology to deliver a packet processing service to flows.
3.2.1. Distributing The Arbitrary Network Function 3.2.1. Distributing The Arbitrary Network Function
The setup in Figure 3 can be split out across 3 FEs instead as The setup in Figure 3 can be split out across 3 FEs instead as
demonstrated in Figure 4. This could be motivated by scale out demonstrated in Figure 4. This could be motivated by scale out
reasons or because different vendors provide different functionality reasons or because different vendors provide different functionality
which is plugged-in to provide such functionality. The end result is which is plugged-in to provide such functionality. The end result is
to have the same packet service delivered to the different flows to have the same packet service delivered to the different flows
skipping to change at page 13, line 7 skipping to change at page 13, line 7
o The ExceptionID TLV carries one or more exception IDs within ILVs. o The ExceptionID TLV carries one or more exception IDs within ILVs.
The I in the ILV carries a globally defined exceptionID as per- The I in the ILV carries a globally defined exceptionID as per-
ForCES specification defined by IANA. This TLV is new to ForCES ForCES specification defined by IANA. This TLV is new to ForCES
and sits in the global ForCES TLV namespace. and sits in the global ForCES TLV namespace.
o The METADATA and REDIRECTDATA TLV encapsulations are taken o The METADATA and REDIRECTDATA TLV encapsulations are taken
directly from [RFC5810] section 7.9. directly from [RFC5810] section 7.9.
It is expected that a variety of transport encapsulations would be It is expected that a variety of transport encapsulations would be
applicable to carry the format described in Figure 6. In such a applicable to carry the format described in Figure 6. In such a
case, a description of a mapping to intepret the inter-FE details and case, a description of a mapping to interpret the inter-FE details
translate into proprietary or legacy formatting would need to be and translate into proprietary or legacy formatting would need to be
defined. For any mapping towards these definitions a different defined. For any mapping towards these definitions a different
document to describe the mapping, one per transport, is expected to document to describe the mapping, one per transport, is expected to
be defined. be defined.
5.1. Inter-FE Ethernet connectivity 5.1. Inter-FE Ethernet Connectivity
In this document, we describe a format that is to be used over In this document, we describe a format that is to be used over
Ethernet. Ethernet. An existing implementation of this specification on top of
Linux Traffic Control [linux-tc] is described in [tc-ife].
The following describes the mapping from Figure 6 to ethernet wire The following describes the mapping from Figure 6 to ethernet wire
encapsulation illustrated in Figure 7. encapsulation illustrated in Figure 7.
o When an NE tag is needed, a VLAN tag will be used. Note: that the o When an NE tag is needed, a VLAN tag will be used. Note: that the
NEID as per Figure 6 is described as being 32 bits while a vlan NEID as per Figure 6 is described as being 32 bits while a vlan
tag is 12 bits. It is however thought to be sufficient to use 12 tag is 12 bits. It is however thought to be sufficient to use 12
bits within the scope of a LAN NE cluster. bits within the scope of a LAN NE cluster.
o An ethernet type will be used to imply that a wire format is o An ethernet type will be used to imply that a wire format is
carrying an inter-FE LFB packet. The ethernet type will be carrying an inter-FE LFB packet. The ethernet type to be used is
requested from the appropriate IEEE Standards Association 0xFEFE (XXX: Note to editor, to be updated when issued by IEEE
(preferred value is 0xFEFE because it maps nicely to the term Standards Association).
FE-FE to imply inter-FE connectivity).
o The destination FEID will be mapped to the destination MAC address o The destination FEID will be mapped to the destination MAC address
of the target FEID. of the target FEID.
o The source FEID will be mapped to the source MAC address of the o The source FEID will be mapped to the source MAC address of the
originating FEID. originating FEID.
o In this version of the specification, we only focus on data and o In this version of the specification, we only focus on data and
metadata. Therefore we are not going to describe how to carry the metadata. Therefore we are not going to describe how to carry the
ExceptionID information (future versions may). We are also not ExceptionID information (future versions may). We are also not
skipping to change at page 14, line 37 skipping to change at page 14, line 37
o The Outer Destination MAC Address carries the Destination FEID o The Outer Destination MAC Address carries the Destination FEID
identification. identification.
o Outer Source MAC Address carries the Source FEID identification. o Outer Source MAC Address carries the Source FEID identification.
o When an NEID is needed, an optional 802.1Q is carried with 12-bit o When an NEID is needed, an optional 802.1Q is carried with 12-bit
VLANid representing the NEID. VLANid representing the NEID.
o The ethernet type is used to identify the frame as inter-FE LFB o The ethernet type is used to identify the frame as inter-FE LFB
type. Ethertype 0xFEFE is to be used (XXX: to be requested). type. Ethertype 0xFEFE is to be used (XXX: Note, to editor update
when available).
o The 16-bit metadata length is used to described the total encoded o The 16-bit metadata length is used to described the total encoded
metadata length (including the 16 bits used to encode the metadata metadata length (including the 16 bits used to encode the metadata
length). length).
o One or more TLV encoded metadatum follows the metadata length o One or more TLV encoded metadatum follows the metadata length
field. The TLV type identifies the Metadata id. ForCES IANA- field. The TLV type identifies the Metadata id. ForCES IANA-
defined Metadata ids will be used. We recognize that using a 16 defined Metadata ids will be used. We recognize that using a 16
bit TLV restricts the metadata id to 16 bits instead of ForCES bit TLV restricts the metadata id to 16 bits instead of ForCES
define space of 32 bits. However, at the time of publication we define space of 32 bits. However, at the time of publication we
believe this is sufficient to carry all the info we need and believe this is sufficient to carry all the info we need and
approach taken would save us 4 bytes per Metadatum transferred. approach taken would save us 4 bytes per Metadatum transferred.
XXX: If there is objection from the we could convert this to an
ILV.
o The original ethernet payload is appended at the end of the o The original ethernet payload is appended at the end of the
metadata as shown. metadata as shown.
5.1.1. Inter-FE Ethernet Connectivity Issues 5.1.1. Inter-FE Ethernet Connectivity Issues
There are several issues that may arise due to using direct ethernet There are several issues that may arise due to using direct ethernet
encapsulation. encapsulation.
o Because we are adding data to existing ethernet frames, MTU issues o Because we are adding data to existing ethernet frames, MTU issues
may arise. We recommend: may arise. We recommend:
* To use large MTUs when possible (example with jumbo frames). * To use large MTUs when possible (example with jumbo frames).
* Limit the amount of metadata that could be transmitted; our * Limit the amount of metadata that could be transmitted; our
definition allows for filtering of which metadata is to be definition allows for filtering of which metadata is to be
encapsulated in the frame. We recommend complementing this by encapsulated in the frame. We recommend implementing this by
setting the egress port MTU to allow space for maximum size of setting the egress port MTU to allow space for maximum size of
the metadata total size you wish to allow between FEs. MTU the metadata total size you wish to allow between FEs. In such
setting can be achieved by configuration or ForCES control of a setup, the port is configured to "lie" to the upper layers by
the port LFB. In essence, the control plane making a decision claiming to have a lower MTU than it is capable of. MTU
setting can be achieved by ForCES control of the port LFB(or
other config). In essence, the control plane making a decision
for the MTU settings of the egress port is implicitly deciding for the MTU settings of the egress port is implicitly deciding
how much metadata will be allowed. how much metadata will be allowed.
o The frame may be dropped if there is congestion on the receiving o The frame may be dropped if there is congestion on the receiving
FE side. One approach to mitigate this issue is to make sure that FE side. One approach to mitigate this issue is to make sure that
inter-FE LFB frames receive the highest priority treatment when inter-FE LFB frames receive the highest priority treatment when
scheduled on the wire. Typically protocols that tunnel in the scheduled on the wire. Typically protocols that tunnel in the
middle box do not care and depend on the packet originator to middle box do not care and depend on the packet originator to
resend if the originator cares about reliability. We do not resend if the originator cares about reliability. We do not
expect to be any different. expect to be any different.
o While we expect to use a unique IEEE-issued ethertype for the o While we expect to use a unique IEEE-issued ethertype for the
inter-FE traffic, we use lessons learnt from VXLAN deployment[XXX: inter-FE traffic, we use lessons learnt from VXLAN deployment xref
ref] to be more flexible on the settings of the ethertype value to be more flexible on the settings of the ethertype value used.
used. We make the etherype an LFB read-write component. Linux We make the ether type an LFB read-write component. Linux VXLAN
VXLAN implementation uses UDP port 8472 because the deployment implementation uses UDP port 8472 because the deployment happened
happened much earlier than the point of RFC publication where the much earlier than the point of RFC publication where the IANA
IANA assigned udp port issued was 4789. For this reason we make assigned udp port issued was 4789 [vxlan-udp]. For this reason we
it possible to define at control time what ethertype to use and make it possible to define at control time what ethertype to use
default to the IEEE issued ethertype. We justify this by assuming and default to the IEEE issued ethertype. We justify this by
that a given ForCES NE is likely to be owned by a single assuming that a given ForCES NE is likely to be owned by a single
organization and that the organization's CE(or CE cluster) could organization and that the organization's CE(or CE cluster) could
program all participating FEs via the inter-FE LFB (described in program all participating FEs via the inter-FE LFB (described in
this document) to recognize a private ethernet type used for this document) to recognize a private ethernet type used for
inter-LFB traffic (possibly those defined as available for private inter-LFB traffic (possibly those defined as available for private
use by the IEEE, namely: IDs 0x88B5 and 0x88B6) use by the IEEE, namely: IDs 0x88B5 and 0x88B6)
6. Detailed Description of the Ethernet inter-FE LFB 6. Detailed Description of the Ethernet inter-FE LFB
The ethernet inter-FE LFB has two LFB input ports and three LFB The ethernet inter-FE LFB has two LFB input ports and three LFB
output ports. output ports.
skipping to change at page 16, line 29 skipping to change at page 16, line 29
| EXCEPTIONOUT +--> ExceptionID, packet + metadata | EXCEPTIONOUT +--> ExceptionID, packet + metadata
| | | |
+-----------------+ +-----------------+
Figure 8: Inter-FE LFB Figure 8: Inter-FE LFB
6.1. Data Handling 6.1. Data Handling
The Inter-FE LFB can be positioned at the egress of a source FE. In The Inter-FE LFB can be positioned at the egress of a source FE. In
such a case an Inter-FE LFB instance receives via port IN1, raw such a case an Inter-FE LFB instance receives via port IN1, raw
packet and metadata IDs from the preceeding LFB instance. The packet and metadata IDs from the preceding LFB instance. The
InterFEid metadatum MAY be present on the incoming raw data. The InterFEid metadatum MAY be present on the incoming raw data. The
processed encapsulated packet will go out on either LFB port OUT1 to processed encapsulated packet will go out on either LFB port OUT1 to
a downstream LFB or EXCEPTIONOUT port in the case of a failure. a downstream LFB or EXCEPTIONOUT port in the case of a failure.
The Inter-FE LFB can be positioned at the ingress of a receiving FE. The Inter-FE LFB can be positioned at the ingress of a receiving FE.
In such a case an Inter-FE LFB receives, via port IN2, an In such a case an Inter-FE LFB receives, via port IN2, an
encapsulated packet. Successful processing of the packet will result encapsulated packet. Successful processing of the packet will result
in a raw packet with associated metadata IDs going downstream to an in a raw packet with associated metadata IDs going downstream to an
LFB connected on OUT2. On failure the data is sent out EXCEPTIONOUT. LFB connected on OUT2. On failure the data is sent out EXCEPTIONOUT.
The Inter-FE LFB may use the InterFEid metadatum on egress of an FE The Inter-FE LFB may use the InterFEid metadatum on egress of an FE
to lookup the IFETable table. The interFEid in such a case will be to lookup the IFETable table. The interFEid in such a case will be
generated by an upstream LFB instance (i.e one preceeding the generated by an upstream LFB instance (i.e one preceding the Inter-FE
Inter-FE LFB). The output result constitutes a matched table row LFB). The output result constitutes a matched table row which has
which has the InterFEinfo details i.e. the tuple {NEID,Destination the InterFEinfo details i.e. the tuple {NEID,Destination FEID,Source
FEID,Source FEID, inter FE type, metafilters}. The metafilters lists FEID, inter FE type, metafilters}. The metafilters lists define
define which Metadatum are to be passed to the neighboring FE. which Metadatum are to be passed to the neighboring FE.
The component names used in describing processing are defined in
Section 6.2
6.1.1. Egress Processing 6.1.1. Egress Processing
The egress Inter-FE LFB will receive an ethernet frame and The egress Inter-FE LFB will receive an ethernet frame and
accompanying metadatum (including optionally the InterFEid metadatum) accompanying metadatum (including optionally the InterFEid metadatum)
at LFB port IN1. The ethernet frame may be 802.1Q tagged. at LFB port IN1. The ethernet frame may be 802.1Q tagged.
The InterFEid may be used to lookup IFETable table. If lookup is The InterFEid may be used to lookup IFETable table. If lookup is
successful, the inter-FE LFB will perform the following actions using successful, the inter-FE LFB will perform the following actions using
the resulting tuple: the resulting tuple:
o Increment statistics for packet and byte count observed. o Increment statistics for packet and byte count observed.
o Walk each passed metadatum apply against the MetaFilterList. If o Walk each packet metadatum and apply against the relevant
no legitimate metadata is found that needs to be passed downstream MetaFilterList. If no legitimate metadata is found that needs to
then the processing stops and the packet is allowed through as is. be passed downstream then the processing stops and the packet is
allowed through as is.
o check that the additional overhead of the outer header and o Check that the additional overhead of the outer header and
encapsulated metadata will not exceed MTU. If it does increment encapsulated metadata will not exceed MTU. If it does, increment
the error packet count statistics and return allowing the packet the error packet count statistics and return allowing the packet
to pass through. (XXX: Should it be dropped because it cannot to pass through.
send the required metadata?)
o create the outer ethernet header which is a duplicate of the o create the outer ethernet header which is a duplicate of the
incoming frame's ethernet header. The outer ethernet header may incoming frame's ethernet header. The outer ethernet header may
have an optional 802.1q header (if one was included in the have an optional 802.1q header (if one was included in the
original frame). original frame).
o If the NEID field is present (not 0) and the original header had a o If the NEID field is present (not 0) and the original header had a
vlan tag, replace the vlan tag on the outer header with the value vlan tag, replace the vlan tag on the outer header with the value
from the matched NEID field. If the NEID field is present (not 0) from the matched NEID field. If the NEID field is present (not 0)
and the original header did not have a vlan tag, create one that and the original header did not have a vlan tag, create one that
skipping to change at page 17, line 51 skipping to change at page 17, line 51
absent, then the inner destination MAC address is used (at this absent, then the inner destination MAC address is used (at this
point already copied). point already copied).
o If the optional SRCFE is present, set the Source MAC address of o If the optional SRCFE is present, set the Source MAC address of
the outer header with value found in the SRCFE field. If SRCFE is the outer header with value found in the SRCFE field. If SRCFE is
absent then the inner source MAC address is used (at this point absent then the inner source MAC address is used (at this point
already copied). already copied).
o If the optional IFETYPE is present, set the outer ethernet type to o If the optional IFETYPE is present, set the outer ethernet type to
the value found in IFETYPE. If IFETYPE is absent then the the value found in IFETYPE. If IFETYPE is absent then the
standard ethernet type is used (XXX: to be requested from IEEE). standard ethernet type is used (XXX: Note to editor, to be
updated).
o encapsulate each allowed metadatum in a TLV. Use the Metaid as o encapsulate each allowed metadatum in a TLV. Use the Metaid as
the "type" field in the TLV header. The TLV should be aligned to the "type" field in the TLV header. The TLV should be aligned to
32 bits. This means you may need to add padding of zeroes to 32 bits. This means you may need to add padding of zeroes to
ensure alignment. ensure alignment.
o Update the Metadata length to the sum of each TLV's space + 2 o Update the Metadata length to the sum of each TLV's space + 2
bytes (for the Metadata length field 16 bit space). bytes (for the Metadata length field 16 bit space).
The resulting packet is sent to the next LFB instance connected to The resulting packet is sent to the next LFB instance connected to
skipping to change at page 18, line 25 skipping to change at page 18, line 25
In the case of a failed lookup or a zero-value InterFEid, (or absence In the case of a failed lookup or a zero-value InterFEid, (or absence
of InterFEid when needed by the implementation) the packet is sent of InterFEid when needed by the implementation) the packet is sent
out unchanged via the OUT1 LFB Class instance port (typically towards out unchanged via the OUT1 LFB Class instance port (typically towards
a Port LFB). a Port LFB).
6.1.2. Ingress Processing 6.1.2. Ingress Processing
An inter-FE LFB packet is recognized by looking at the etherype An inter-FE LFB packet is recognized by looking at the etherype
received on LFB instance port IN2. The IFETable table may be received on LFB instance port IN2. The IFETable table may be
optionally utilized to provide metadata filters (XXX: Should we allow optionally utilized to provide metadata filters.
for the interFEid metadata to be sent by the neighbor FE and use it
here? Implementations dont need it to associate a specific port/MAC/
VLAN etc with the IFETable LFB).
o Increment statistics for packet and byte count observed. o Increment statistics for packet and byte count observed.
o The inter-FE LFB instance looks at the metadata length field and o Look at the metadata length field and walk the packet data
walks the packet data extracting from the TLVs the metadata extracting from the TLVs the metadata values. For each metadatum
values. For each metadatum extracted, optionally the metaid is extracted, the metaid is compared against the relevant IFETable
compared against the relevant IFETable row metafilter list. If row metafilter list. If the metadatum is recognized, and is
the metadatum is recognized and is allowed by the filter the allowed by the filter the corresponding implementation metadatum
corresponding implementation metadatum field is set. If an field is set. If an unknown metadatum id is encountered, or if
unknown metadatum id is encountered, or if the metaid is not found the metaid is not found in the option allowed filter list the
in the option allowed filter list the implementation is expected implementation is expected to ignore it, increment the packet
to ignore it, increment the packet error statistic and proceed error statistic and proceed processing other metadatum.
processing other metadatum.
o Upon completion of processing all the metadata, the inter-FE LFB o Upon completion of processing all the metadata, the inter-FE LFB
instance resets the header to point to the original (inner) instance resets the header to point to the original (inner)
ethernet header i.e skips the metadata information. At this point ethernet header i.e skips the IFE header information. At this
the the original ethernet frame that was passed to the egress point the the original ethernet frame that was passed to the
Inter-FE LFB at the source FE is reconstructed. This data is then egress Inter-FE LFB at the source FE is reconstructed. This data
passed along with the reconstructed metadata downstream to the is then passed along with the reconstructed metadata downstream to
next LFB instance in the graph. the next LFB instance in the graph.
In the case of processing failure of either ingress or egress In the case of processing failure of either ingress or egress
positioning of the LFB, the packet and metadata are sent out the positioning of the LFB, the packet and metadata are sent out the
EXCEPTIONOUT LFB port with proper error id (XXX: More description to EXCEPTIONOUT LFB port with appropriate error id. Note that the
be added). EXCEPTIONOUT LFB port is merely an abstraction and implementation may
in fact drop packets as described above.
6.2. Components 6.2. Components
There are two LFB component populated by the CE. There are two LFB component populated by the CE.
The CE optionally programs LFB instances in a service graph that The CE optionally programs LFB instances in a service graph that
require inter-FE connectivity with InterFEid values to correspond to require inter-FE connectivity with InterFEid values to correspond to
the inter-FE LFB IFETable table entries to use. the inter-FE LFB IFETable table entries to use.
The first component is an array known as the IFETable table. The The first component is an array known as the IFETable table. The
skipping to change at page 19, line 31 skipping to change at page 19, line 29
metadatum. metadatum.
The second component(ID 2) is IFEStats table which carries the basic The second component(ID 2) is IFEStats table which carries the basic
stats structure bstats. The table index value used to lookup this stats structure bstats. The table index value used to lookup this
table is the same one as in IFETable table; in other words for a table is the same one as in IFETable table; in other words for a
table row index 10 in the IFETable table, its corresponding stats table row index 10 in the IFETable table, its corresponding stats
will be found in row index of the IFEStats table. will be found in row index of the IFEStats table.
6.3. Inter-FE LFB XML Model 6.3. Inter-FE LFB XML Model
XXX: metadata definition requires clarification. We expect to use
IANA defined metadatum. How do we describe them here in the model?
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="IFE"> provides="IFE">
<frameDefs> <frameDefs>
<frameDef> <frameDef>
<name>EthernetAny</name> <name>EthernetAny</name>
<synopsis>Packet with any Ethernet type</synopsis> <synopsis>Packet with any Ethernet type</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
skipping to change at page 21, line 22 skipping to change at page 21, line 17
<name>SRCFE</name> <name>SRCFE</name>
<synopsis> <synopsis>
the source MAC address used for the source FE the source MAC address used for the source FE
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>byte[6]</typeRef> <typeRef>byte[6]</typeRef>
</component> </component>
<component componentID="5"> <component componentID="5">
<name>MetaFilterList</name> <name>MetaFilterList</name>
<synopsis> <synopsis>
the metadata filter table the allowed metadata filter table
</synopsis> </synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array> </array>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
skipping to change at page 21, line 50 skipping to change at page 21, line 45
</synopsis> </synopsis>
<metadataID>16</metadataID> <metadataID>16</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
</metadataDefs> </metadataDefs>
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="6612"> <LFBClassDef LFBClassID="6612">
<name>IFE</name> <name>IFE</name>
<synopsis> <synopsis>
This LFB describes IFE connectivity parametrization This LFB describes IFE connectivity parameterization
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>IN1</name> <name>IN1</name>
<synopsis> <synopsis>
The input port of the egress side. The input port of the egress side.
It expects any type of Ethernet frame. It expects any type of Ethernet frame.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>EthernetAny</ref> <ref>EthernetAny</ref>
</frameExpected> </frameExpected>
skipping to change at page 24, line 41 skipping to change at page 24, line 36
https://www.iana.org/assignments/forces https://www.iana.org/assignments/forces
The first request is for the sub-registry "Logical Functional Block The first request is for the sub-registry "Logical Functional Block
(LFB) Class Names and Class Identifiers" to request for the (LFB) Class Names and Class Identifiers" to request for the
reservation of LFB class name IFE with LFB classid 6112 with version reservation of LFB class name IFE with LFB classid 6112 with version
1.0. 1.0.
The second request is for the sub-registry "Metadata ID" to request The second request is for the sub-registry "Metadata ID" to request
for the InterFEid metadata the value 0x00000010. for the InterFEid metadata the value 0x00000010.
9. Security Considerations 9. IEEE Assignment Considerations
XXX:TBD This memo includes a request for a new ethernet protocol type as
described in Section 5.1.
10. References 10. Security Considerations
10.1. Normative References
This document does not alter either the ForCES model the ForCES Model
[RFC5812] or the ForCES Protocol [RFC5810] As such, it has no impact
on their security considerations. This document simply defines the
operational parameters and capabilities of an LFB that performs LFB
class instance extensions across nodes under a single administrative
control. this document does not attempt to analyze the presence or
possibility of security interactions created by allowing LFB graph
extension on packets. Any such issues, if they exist, are for the
designers of the particular data path, not the general mechanism.
11. References
11.1. Normative References
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004. Framework", RFC 3746, April 2004.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010. Specification", RFC 5810, March 2010.
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
Layer (TML) for the Forwarding and Control Element Layer (TML) for the Forwarding and Control Element
Separation (ForCES) Protocol", RFC 5811, March 2010. Separation (ForCES) Protocol", RFC 5811, March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model", Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010. RFC 5812, March 2010.
10.2. Informative References 11.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, 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,
June 2013.
[brcm-higig]
"Higig", <http://www.broadcom.com/products/brands/HiGig>.
[linux-tc]
Hadi Salim, J., "Linux Traffic Control Classifier-Action
Subsystem Architecture", netdev 01, Feb 2015.
[tc-ife] Hadi Salim, J. and D. Joachimpillai, "Distributing Linux
Traffic Control Classifier-Action Subsystem", netdev 01,
Feb 2015.
[vxlan-udp]
"iproute2 and kernel code (drivers/net/vxlan.c)",
<https://www.kernel.org/pub/linux/utils/net/iproute2/>.
Authors' Addresses Authors' Addresses
Damascane M. Joachimpillai Damascane M. Joachimpillai
Verizon Verizon
60 Sylvan Rd 60 Sylvan Rd
Waltham, Mass. 02451 Waltham, Mass. 02451
USA USA
Email: damascene.joachimpillai@verizon.com Email: damascene.joachimpillai@verizon.com
 End of changes. 38 change blocks. 
91 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/