idnits 2.17.1
draft-ietf-forces-interfelfb-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 854 has weird spacing: '...putPort group...'
-- The document date (July 1, 2016) is 2856 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC 791' is mentioned on line 463, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. 'ieee8021ae'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ieee8021x'
-- Obsolete informational reference (is this intentional?): RFC 2460
(Obsoleted by RFC 8200)
Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force D. Joachimpillai
3 Internet-Draft Verizon
4 Intended status: Standards Track J. Hadi Salim
5 Expires: January 2, 2017 Mojatatu Networks
6 July 1, 2016
8 ForCES Inter-FE LFB
9 draft-ietf-forces-interfelfb-06
11 Abstract
13 This document describes how to extend the ForCES LFB topology across
14 FEs by defining the Inter-FE LFB Class. The Inter-FE LFB Class
15 provides the ability to pass data and metadata across FEs without
16 needing any changes to the ForCES specification. The document
17 focuses on Ethernet transport.
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at http://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on January 2, 2017.
36 Copyright Notice
38 Copyright (c) 2016 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
51 Table of Contents
53 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 2
54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
55 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
57 3. Problem Scope And Use Cases . . . . . . . . . . . . . . . . . 4
58 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
59 3.2. Sample Use Cases . . . . . . . . . . . . . . . . . . . . 4
60 3.2.1. Basic IPv4 Router . . . . . . . . . . . . . . . . . . 4
61 3.2.1.1. Distributing The Basic IPv4 Router . . . . . . . 6
62 3.2.2. Arbitrary Network Function . . . . . . . . . . . . . 7
63 3.2.2.1. Distributing The Arbitrary Network Function . . . 8
64 4. Inter-FE LFB Overview . . . . . . . . . . . . . . . . . . . . 8
65 4.1. Inserting The Inter-FE LFB . . . . . . . . . . . . . . . 9
66 5. Inter-FE Ethernet Connectivity . . . . . . . . . . . . . . . 10
67 5.1. Inter-FE Ethernet Connectivity Issues . . . . . . . . . . 10
68 5.1.1. MTU Consideration . . . . . . . . . . . . . . . . . . 11
69 5.1.2. Quality Of Service Considerations . . . . . . . . . . 11
70 5.1.3. Congestion Considerations . . . . . . . . . . . . . . 11
71 5.2. Inter-FE Ethernet Encapsulation . . . . . . . . . . . . . 12
72 6. Detailed Description of the Ethernet inter-FE LFB . . . . . . 13
73 6.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 14
74 6.1.1. Egress Processing . . . . . . . . . . . . . . . . . . 14
75 6.1.2. Ingress Processing . . . . . . . . . . . . . . . . . 15
76 6.2. Components . . . . . . . . . . . . . . . . . . . . . . . 16
77 6.3. Inter-FE LFB XML Model . . . . . . . . . . . . . . . . . 17
78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
80 9. IEEE Assignment Considerations . . . . . . . . . . . . . . . 22
81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
83 11.1. Normative References . . . . . . . . . . . . . . . . . . 23
84 11.2. Informative References . . . . . . . . . . . . . . . . . 24
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
87 1. Terminology and Conventions
88 1.1. Requirements Language
90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
92 document are to be interpreted as described in [RFC2119].
94 1.2. Definitions
96 This document depends on the terminology defined in several ForCES
97 documents [RFC3746], [RFC5810], [RFC5811], and [RFC5812] [RFC7391]
98 [RFC7408] for the sake of contextual clarity.
100 Control Engine (CE)
102 Forwarding Engine (FE)
104 FE Model
106 LFB (Logical Functional Block) Class (or type)
108 LFB Instance
110 LFB Model
112 LFB Metadata
114 ForCES Component
116 LFB Component
118 ForCES Protocol Layer (ForCES PL)
120 ForCES Protocol Transport Mapping Layer (ForCES TML)
122 2. Introduction
124 In the ForCES architecture, a packet service can be modelled by
125 composing a graph of one or more LFB instances. The reader is
126 referred to the details in the ForCES Model [RFC5812].
128 The ForCES model describes the processing within a single Forwarding
129 Element (FE) in terms of logical forwarding blocks (LFB), including
130 provision for the Control Element (CE) to establish and modify that
131 processing sequence, and the parameters of the individual LFBs.
133 Under some circumstance, it would be beneficial to be able to extend
134 this view, and the resulting processing across more than one FE.
135 This may be in order to achieve scale by splitting the processing
136 across elements, or to utilize specialized hardware available on
137 specific FEs.
139 Given that the ForCES inter-LFB architecture calls for the ability to
140 pass metadata between LFBs, it is imperative therefore to define
141 mechanisms to extend that existing feature and allow passing the
142 metadata between LFBs across FEs.
144 This document describes how to extend the LFB topology across FEs i.e
145 inter-FE connectivity without needing any changes to the ForCES
146 definitions. It focuses on using Ethernet as the interconnection
147 between FEs.
149 3. Problem Scope And Use Cases
151 The scope of this document is to solve the challenge of passing
152 ForCES defined metadata alongside packet data across FEs (be they
153 physical or virtual) for the purpose of distributing the LFB
154 processing.
156 3.1. Assumptions
158 o The FEs involved in the Inter-FE LFB belong to the same Network
159 Element(NE) and are within a single administrative private network
160 which is in close proximity.
162 o The FEs are already interconnected using Ethernet. We focus on
163 Ethernet because it is a very common setup as an FE interconnect.
164 Other higher transports (such as UDP over IP) or lower transports
165 could be defined to carry the data and metadata, but these cases
166 are not addressed in this document.
168 3.2. Sample Use Cases
170 To illustrate the problem scope we present two use cases where we
171 start with a single FE running all the LFBs functionality then split
172 it into multiple FEs achieving the same end goals.
174 3.2.1. Basic IPv4 Router
176 A sample LFB topology depicted in Figure 1 demonstrates a service
177 graph for delivering basic IPv4 forwarding service within one FE.
178 For the purpose of illustration, the diagram shows LFB classes as
179 graph nodes instead of multiple LFB class instances.
181 Since the illustration on Figure 1 is meant only as an exercise to
182 showcase how data and metadata are sent down or upstream on a graph
183 of LFB instances, it abstracts out any ports in both directions and
184 talks about a generic ingress and egress LFB. Again, for
185 illustration purposes, the diagram does not show exception or error
186 paths. Also left out are details on Reverse Path Filtering, ECMP,
187 multicast handling etc. In other words, this is not meant to be a
188 complete description of an IPv4 forwarding application; for a more
189 complete example, please refer the LFBlib document [RFC6956].
191 The output of the ingress LFB(s) coming into the IPv4 Validator LFB
192 will have both the IPv4 packets and, depending on the implementation,
193 a variety of ingress metadata such as offsets into the different
194 headers, any classification metadata, physical and virtual ports
195 encountered, tunnelling information etc. These metadata are lumped
196 together as "ingress metadata".
198 Once the IPv4 validator vets the packet (example ensures that no
199 expired TTL etc), it feeds the packet and inherited metadata into the
200 IPv4 unicast LPM LFB.
202 +----+
203 | |
204 IPv4 pkt | | IPv4 pkt +-----+ +---+
205 +------------->| +------------->| | | |
206 | + ingress | | + ingress |IPv4 | IPv4 pkt | |
207 | metadata | | metadata |Ucast+------------>| +--+
208 | +----+ |LPM | + ingress | | |
209 +-+-+ IPv4 +-----+ + NHinfo +---+ |
210 | | Validator metadata IPv4 |
211 | | LFB NextHop|
212 | | LFB |
213 | | |
214 | | IPv4 pkt |
215 | | + {ingress |
216 +---+ + NHdetails}
217 Ingress metadata |
218 LFB +--------+ |
219 | Egress | |
220 <--+ |<-----------------+
221 | LFB |
222 +--------+
224 Figure 1: Basic IPv4 packet service LFB topology
226 The IPv4 unicast LPM LFB does a longest prefix match lookup on the
227 IPv4 FIB using the destination IP address as a search key. The
228 result is typically a next hop selector which is passed downstream as
229 metadata.
231 The Nexthop LFB receives the IPv4 packet with an associated next hop
232 info metadata. The NextHop LFB consumes the NH info metadata and
233 derives from it a table index to look up the next hop table in order
234 to find the appropriate egress information. The lookup result is
235 used to build the next hop details to be used downstream on the
236 egress. This information may include any source and destination
237 information (for our purposes, MAC addresses to use) as well as
238 egress ports. [Note: It is also at this LFB where typically the
239 forwarding TTL decrementing and IP checksum recalculation occurs.]
241 The details of the egress LFB are considered out of scope for this
242 discussion. Suffice it is to say that somewhere within or beyond the
243 Egress LFB the IPv4 packet will be sent out a port (Ethernet, virtual
244 or physical etc).
246 3.2.1.1. Distributing The Basic IPv4 Router
248 Figure 2 demonstrates one way the router LFB topology in Figure 1 may
249 be split across two FEs (eg two ASICs). Figure 2 shows the LFB
250 topology split across FEs after the IPv4 unicast LPM LFB.
252 FE1
253 +-------------------------------------------------------------+
254 | +----+ |
255 | +----------+ | | |
256 | | Ingress | IPv4 pkt | | IPv4 pkt +-----+ |
257 | | LFB +-------------->| +------------->| | |
258 | | | + ingress | | + ingress |IPv4 | |
259 | +----------+ metadata | | metadata |Ucast| |
260 | ^ +----+ |LPM | |
261 | | IPv4 +--+--+ |
262 | | Validator | |
263 | LFB | |
264 +---------------------------------------------------|---------+
265 |
266 IPv4 packet +
267 {ingress + NHinfo}
268 metadata
269 FE2 |
270 +---------------------------------------------------|---------+
271 | V |
272 | +--------+ +--------+ |
273 | | Egress | IPv4 packet | IPv4 | |
274 | <-----+ LFB |<----------------------+NextHop | |
275 | | |{ingress + NHdetails} | LFB | |
276 | +--------+ metadata +--------+ |
277 +-------------------------------------------------------------+
279 Figure 2: Split IPv4 packet service LFB topology
281 Some proprietary inter-connect (example Broadcom HiGig over XAUI
282 [brcm-higig]) are known to exist to carry both the IPv4 packet and
283 the related metadata between the IPv4 Unicast LFB and IPv4 NextHop
284 LFB across the two FEs.
286 This document defines the inter-FE LFB, a standard mechanism for
287 encapsulating, generating, receiving and decapsulating packets and
288 associated metadata FEs over Ethernet.
290 3.2.2. Arbitrary Network Function
292 In this section we show an example of an arbitrary Network Function
293 which is more coarse grained in terms of functionality. Each Network
294 Function may constitute more than one LFB.
296 FE1
297 +-------------------------------------------------------------+
298 | +----+ |
299 | +----------+ | | |
300 | | Network | pkt |NF2 | pkt +-----+ |
301 | | Function +-------------->| +------------->| | |
302 | | 1 | + NF1 | | + NF1/2 |NF3 | |
303 | +----------+ metadata | | metadata | | |
304 | ^ +----+ | | |
305 | | +--+--+ |
306 | | | |
307 | | |
308 +---------------------------------------------------|---------+
309 V
311 Figure 3: A Network Function Service Chain within one FE
313 The setup in Figure 3 is a typical of most packet processing boxes
314 where we have functions like DPI, NAT, Routing, etc connected in such
315 a topology to deliver a packet processing service to flows.
317 3.2.2.1. Distributing The Arbitrary Network Function
319 The setup in Figure 3 can be split out across 3 FEs instead of as
320 demonstrated in Figure 4. This could be motivated by scale out
321 reasons or because different vendors provide different functionality
322 which is plugged-in to provide such functionality. The end result is
323 to have the same packet service delivered to the different flows
324 passing through.
326 FE1 FE2
327 +----------+ +----+ FE3
328 | Network | pkt |NF2 | pkt +-----+
329 | Function +-------------->| +------------->| |
330 | 1 | + NF1 | | + NF1/2 |NF3 |
331 +----------+ metadata | | metadata | |
332 ^ +----+ | |
333 | +--+--+
334 |
335 V
337 Figure 4: A Network Function Service Chain Distributed Across
338 Multiple FEs
340 4. Inter-FE LFB Overview
342 We address the inter-FE connectivity requirements by defining the
343 inter-FE LFB class. Using a standard LFB class definition implies no
344 change to the basic ForCES architecture in the form of the core LFBs
345 (FE Protocol or Object LFBs). This design choice was made after
346 considering an alternative approach that would have required changes
347 to both the FE Object capabilities (SupportedLFBs) as well
348 LFBTopology component to describe the inter-FE connectivity
349 capabilities as well as runtime topology of the LFB instances.
351 4.1. Inserting The Inter-FE LFB
353 The distributed LFB topology described in Figure 2 is re-illustrated
354 in Figure 5 to show the topology location where the inter-FE LFB
355 would fit in.
357 As can be observed in Figure 5, the same details passed between IPv4
358 unicast LPM LFB and the IPv4 NH LFB are passed to the egress side of
359 the Inter-FE LFB. This information is illustrated as multiplicity of
360 inputs into the egress InterFE LFB instance. Each input represents a
361 unique set of selection information.
363 FE1
364 +-------------------------------------------------------------+
365 | +----------+ +----+ |
366 | | Ingress | IPv4 pkt | | IPv4 pkt +-----+ |
367 | | LFB +-------------->| +------------->| | |
368 | | | + ingress | | + ingress |IPv4 | |
369 | +----------+ metadata | | metadata |Ucast| |
370 | ^ +----+ |LPM | |
371 | | IPv4 +--+--+ |
372 | | Validator | |
373 | | LFB | |
374 | | IPv4 pkt + metadata |
375 | | {ingress + NHinfo} |
376 | | | |
377 | | +..--+..+ |
378 | | |..| | | |
379 | +-V--V-V--V-+ |
380 | | Egress | |
381 | | InterFE | |
382 | | LFB | |
383 | +------+----+ |
384 +---------------------------------------------------|---------+
385 |
386 Ethernet Frame with: |
387 IPv4 packet data and metadata
388 {ingress + NHinfo + Inter FE info}
389 FE2 |
390 +---------------------------------------------------|---------+
391 | +..+.+..+ |
392 | |..|.|..| |
393 | +-V--V-V--V-+ |
394 | | Ingress | |
395 | | InterFE | |
396 | | LFB | |
397 | +----+------+ |
398 | | |
399 | IPv4 pkt + metadata |
400 | {ingress + NHinfo} |
401 | | |
402 | +--------+ +----V---+ |
403 | | Egress | IPv4 packet | IPv4 | |
404 | <-----+ LFB |<----------------------+NextHop | |
405 | | |{ingress + NHdetails} | LFB | |
406 | +--------+ metadata +--------+ |
407 +-------------------------------------------------------------+
409 Figure 5: Split IPv4 forwarding service with Inter-FE LFB
411 The egress of the inter-FE LFB uses the received packet and metadata
412 to select details for encapsulation when sending messages towards the
413 selected neighboring FE. These details include what to communicate
414 as the source and destination FEs (abstracted as MAC addresses as
415 described in Section 5.2); in addition the original metadata may be
416 passed along with the original IPv4 packet.
418 On the ingress side of the inter-FE LFB the received packet and its
419 associated metadata are used to decide the packet graph continuation.
420 This includes which of the original metadata and which next LFB class
421 instance to continue processing on. In the illustrated Figure 5, an
422 IPv4 Nexthop LFB instance is selected and appropriate metadata is
423 passed on to it.
425 The ingress side of the inter-FE LFB consumes some of the information
426 passed and passes on the IPv4 packet alongside with the ingress and
427 NHinfo metadata to the IPv4 NextHop LFB as was done earlier in both
428 Figure 1 and Figure 2.
430 5. Inter-FE Ethernet Connectivity
432 Section 5.1 describes some of the issues related to using Ethernet as
433 the transport and how we mitigate them.
435 Section 5.2 defines a payload format that is to be used over
436 Ethernet. An existing implementation of this specification on top of
437 Linux Traffic Control [linux-tc] is described in [tc-ife].
439 5.1. Inter-FE Ethernet Connectivity Issues
441 There are several issues that may occur due to using direct Ethernet
442 encapsulation that need consideration.
444 5.1.1. MTU Consideration
446 Because we are adding data to existing Ethernet frames, MTU issues
447 may arise. We recommend:
449 o To use large MTUs when possible (example with jumbo frames).
451 o Limit the amount of metadata that could be transmitted; our
452 definition allows for filtering of select metadata to be
453 encapsulated in the frame as described in Section 6. We recommend
454 sizing the egress port MTU so as to allow space for maximum size
455 of the metadata total size to allow between FEs. In such a setup,
456 the port is configured to "lie" to the upper layers by claiming to
457 have a lower MTU than it is capable of. MTU setting can be
458 achieved by ForCES control of the port LFB(or other config). In
459 essence, the control plane when explicitly making a decision for
460 the MTU settings of the egress port is implicitly deciding how
461 much metadata will be allowed. Caution needs to be exercised on
462 how low the resulting reported link MTU could be: For IPv4 packets
463 the minimum size is 64 octets [RFC 791] and for IPv6 the minimum
464 size is 1280 octets [RFC2460].
466 5.1.2. Quality Of Service Considerations
468 A raw packet arriving at the Inter-FE LFB (from upstream LFB Class
469 instances) may have COS metadatum indicating how it should be treated
470 from a Quality of Service perspective.
472 The resulting Ethernet frame will be eventually (preferentially)
473 treated by a downstream LFB(typically a port LFB instance) and their
474 COS marks will be honored in terms of priority. In other words the
475 presence of the Inter-FE LFB does not change the COS semantics
477 5.1.3. Congestion Considerations
479 Most of the traffic passing through FEs that utilize the Inter-FE LFB
480 is expected to be IP based, which is generally assumed to be
481 congestion controlled [draft-ietf-tsvwg-rfc5405bis]. For example if
482 congestion causes a TCP packet annotated with additional ForCES
483 metadata to be dropped between FEs, the sending TCP can be expected
484 to react in the same fashion as if that packet had been dropped at a
485 different point on its path where ForCES is not involved. For this
486 reason, additional Inter-FE congestion control mechanisms are not
487 specified.
489 However, the increased packet size due to addition of ForCES metadata
490 is likely to require additional bandwidth on inter-FE links by
491 comparison to what would be required to carry the same traffic
492 without ForCES metadata. Therefore, traffic engineering SHOULD be
493 done when deploying Inter-FE encapsulation.
495 Furthermore, the Inter-FE LFB MUST only be deployed within a single
496 network (with a single network operator) or networks of an adjacent
497 set of cooperating network operators where traffic is managed to
498 avoid congestion. These are Controlled Environments, as defined by
499 Section 3.6 of [draft-ietf-tsvwg-rfc5405bis]. Additional measures
500 SHOULD be imposed to restrict the impact of Inter-FE encapsulated
501 traffic on other traffic; example:
503 o rate limiting at an upstream LFB all Inter-FE LFB traffic
505 o managed circuit breaking[circuit-b].
507 o Isolating the Inter-FE traffic either via dedicated interfaces or
508 VLANs.
510 5.2. Inter-FE Ethernet Encapsulation
512 The Ethernet wire encapsulation is illustrated in Figure 6. The
513 process that leads to this encapsulation is described in Section 6.
514 The resulting frame is 32 bit aligned.
516 0 1 2 3
517 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
519 | Destination MAC Address |
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
521 | Destination MAC Address | Source MAC Address |
522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
523 | Source MAC Address |
524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
525 | Inter-FE ethertype | Metadata length |
526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
527 | TLV encoded Metadata ~~~..............~~ |
528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
529 | TLV encoded Metadata ~~~..............~~ |
530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
531 | Original packet data ~~................~~ |
532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
534 Figure 6: Packet format definition
536 The Ethernet header (illustrated in Figure 6) has the following
537 semantics:
539 o The Destination MAC Address is used to identify the Destination
540 FEID by the CE policy (as described in Section 6).
542 o The Source MAC Address is used to identify the Source FEID by the
543 CE policy (as described in Section 6).
545 o The Ethernet type is used to identify the frame as inter-FE LFB
546 type. Ethertype TBA1 is to be used (XXX: Note to RFC editor -
547 update when available).
549 o The 16-bit metadata length is used to described the total encoded
550 metadata length (including the 16 bits used to encode the metadata
551 length).
553 o One or more 16-bit TLV encoded Metadatum follows the metadata
554 length field. The TLV type identifies the Metadata id. ForCES
555 IANA-defined Metadata ids will be used. All TLVs will be 32 bit
556 aligned. We recognize that using a 16 bit TLV restricts the
557 metadata id to 16 bits instead of ForCES-defined component ID
558 space of 32 bits if an ILV is used. However, at the time of
559 publication we believe this is sufficient to carry all the info we
560 need; the TLV approach has been selected because it saves us 4
561 bytes per Metadatum transferred as compared to the ILV approach.
563 o The original packet data payload is appended at the end of the
564 metadata as shown.
566 6. Detailed Description of the Ethernet inter-FE LFB
568 The Ethernet inter-FE LFB has two LFB input port groups and three LFB
569 output ports as shown in Figure 7.
571 The inter-FE LFB defines two components used in aiding processing
572 described in Section 6.2.
574 +-----------------+
575 Inter-FE LFB | |
576 Encapsulated | OUT2+--> decapsulated Packet
577 -------------->|IngressInGroup | + metadata
578 Ethernet Frame | |
579 | |
580 raw Packet + | OUT1+--> Encapsulated Ethernet
581 -------------->|EgressInGroup | Frame
582 Metadata | |
583 | EXCEPTIONOUT +--> ExceptionID, packet
584 | | + metadata
585 +-----------------+
586 Figure 7: Inter-FE LFB
588 6.1. Data Handling
590 The Inter-FE LFB (instance) can be positioned at the egress of a
591 source FE. Figure 5 illustrates an example source FE in the form of
592 FE1. In such a case an Inter-FE LFB instance receives, via port
593 group EgressInGroup, a raw packet and associated metadata from the
594 preceding LFB instances. The input information is used to produce a
595 selection of how to generate and encapsulate the new frame. The set
596 of all selections is stored in the LFB component IFETable described
597 further below. The processed encapsulated Ethernet Frame will go out
598 on OUT1 to a downstream LFB instance when processing succeeds or to
599 the EXCEPTIONOUT port in the case of a failure.
601 The Inter-FE LFB (instance) can be positioned at the ingress of a
602 receiving FE. Figure 5 illustrates an example destination FE in the
603 form of FE1. In such a case an Inter-FE LFB receives, via an LFB
604 port in the IngressInGroup, an encapsulated Ethernet frame.
605 Successful processing of the packet will result in a raw packet with
606 associated metadata IDs going downstream to an LFB connected on OUT2.
607 On failure the data is sent out EXCEPTIONOUT.
609 6.1.1. Egress Processing
611 The egress Inter-FE LFB receives packet data and any accompanying
612 Metadatum at an LFB port of the LFB instance's input port group
613 labelled EgressInGroup.
615 The LFB implementation may use the incoming LFB port (within LFB port
616 group EgressInGroup) to map to a table index used to lookup the
617 IFETable table.
619 If lookup is successful, a matched table row which has the
620 InterFEinfo details is retrieved with the tuple {optional IFEtype,
621 optional StatId, Destination MAC address(DSTFE), Source MAC
622 address(SRCFE), optional metafilters}. The metafilters lists define
623 a whitelist of which Metadatum are to be passed to the neighboring
624 FE. The inter-FE LFB will perform the following actions using the
625 resulting tuple:
627 o Increment statistics for packet and byte count observed at
628 corresponding IFEStats entry.
630 o When MetaFilterList is present, then walk each received Metadatum
631 and apply against the MetaFilterList. If no legitimate metadata
632 is found that needs to be passed downstream then the processing
633 stops and send the packet and metadata out the EXCEPTIONOUT port
634 with exceptionID of EncapTableLookupFailed [RFC6956].
636 o Check that the additional overhead of the Ethernet header and
637 encapsulated metadata will not exceed MTU. If it does, increment
638 the error packet count statistics and send the packet and metadata
639 out the EXCEPTIONOUT port with exceptionID of FragRequired
640 [RFC6956].
642 o Create the Ethernet header
644 o Set the Destination MAC address of the Ethernet header with value
645 found in the DSTFE field.
647 o Set the Source MAC address of the Ethernet header with value found
648 in the SRCFE field.
650 o If the optional IFETYPE is present, set the Ethernet type to the
651 value found in IFETYPE. If IFETYPE is absent then the standard
652 Inter-FE LFB Ethernet type TBA1 is used (XXX: Note to RFC editor -
653 update when available).
655 o Encapsulate each allowed Metadatum in a TLV. Use the Metaid as
656 the "type" field in the TLV header. The TLV should be aligned to
657 32 bits. This means you may need to add padding of zeroes at the
658 end of the TLV to ensure alignment.
660 o Update the Metadata length to the sum of each TLV's space plus 2
661 bytes (for the Metadata length field 16 bit space).
663 The resulting packet is sent to the next LFB instance connected to
664 the OUT1 LFB-port; typically a port LFB.
666 In the case of a failed lookup the original packet and associated
667 metadata is sent out the EXCEPTIONOUT port with exceptionID of
668 EncapTableLookupFailed [RFC6956]. Note that the EXCEPTIONOUT LFB
669 port is merely an abstraction and implementation may in fact drop
670 packets as described above.
672 6.1.2. Ingress Processing
674 An ingressing inter-FE LFB packet is recognized by inspecting the
675 ethertype, and optionally the destination and source MAC addresses.
676 A matching packet is mapped to an LFB instance port in the
677 IngressInGroup. The IFETable table row entry matching the LFB
678 instance port may have optionally programmed metadata filters. In
679 such a case the ingress processing should use the metadata filters as
680 a whitelist of what metadatum is to be allowed.
682 o Increment statistics for packet and byte count observed.
684 o Look at the metadata length field and walk the packet data
685 extracting from the TLVs the metadata values. For each Metadatum
686 extracted, in the presence of metadata filters, the metaid is
687 compared against the relevant IFETable row metafilter list. If
688 the Metadatum is recognized, and is allowed by the filter, the
689 corresponding implementation Metadatum field is set. If an
690 unknown Metadatum id is encountered, or if the metaid is not in
691 the allowed filter list the implementation is expected to ignore
692 it, increment the packet error statistic and proceed processing
693 other Metadatum.
695 o Upon completion of processing all the metadata, the inter-FE LFB
696 instance resets the data point to the original payload (i.e skips
697 the IFE header information). At this point the original packet
698 that was passed to the egress Inter-FE LFB at the source FE is
699 reconstructed. This data is then passed along with the
700 reconstructed metadata downstream to the next LFB instance in the
701 graph.
703 In the case of processing failure of either ingress or egress
704 positioning of the LFB, the packet and metadata are sent out the
705 EXCEPTIONOUT LFB port with appropriate error id. Note that the
706 EXCEPTIONOUT LFB port is merely an abstraction and implementation may
707 in fact drop packets as described above.
709 6.2. Components
711 There are two LFB components accessed by the CE. The reader is asked
712 to refer to the definitions in Figure 8.
714 The first component, populated by the CE, is an array known as the
715 IFETable table. The array rows are made up of IFEInfo structure.
716 The IFEInfo structure constitutes: optional IFETYPE, optionally
717 present StatId, Destination MAC address(DSTFE), Source MAC
718 address(SRCFE), optionally present array of allowed Metaids
719 (MetaFilterList).
721 The second component(ID 2), populated by the FE and read by the CE,
722 is an indexed array known as the IFEStats table. Each IFEStats row
723 which carries statistics information in the structure bstats.
725 A note about the StatId relationship between the IFETable table and
726 IFEStats table: An implementation may choose to map between an
727 IFETable row and IFEStats table row using the StatId entry in the
728 matching IFETable row. In that case the IFETable StatId must be
729 present. Alternative implementation may map at provisioning time an
730 IFETable row to IFEStats table row. Yet another alternative
731 implementation may choose not to use the IFETable row StatId and
732 instead use the IFETable row index as the IFEStats index. For these
733 reasons the StatId component is optional.
735 6.3. Inter-FE LFB XML Model
737
740
742
743 PacketAny
744 Arbitrary Packet
745
746
747 InterFEFrame
748
749 Ethernet Frame with encapsulate IFE information
750
751
753
755
757
758 bstats
759 Basic stats
760
761
762 bytes
763 The total number of bytes seen
764 uint64
765
767
768 packets
769 The total number of packets seen
770 uint32
771
772
773 errors
774 The total number of packets with errors
775 uint32
776
777
779
781
782 IFEInfo
783 Describing IFE table row Information
784
785
786 IFETYPE
787
788 the ethernet type to be used for outgoing IFE frame
789
790
791 uint16
792
793
794 StatId
795
796 the Index into the stats table
797
798
799 uint32
800
801
802 DSTFE
803
804 the destination MAC address of destination FE
805
806 byte[6]
807
808
809 SRCFE
810
811 the source MAC address used for the source FE
812
813 byte[6]
814
815
816 MetaFilterList
817
818 the allowed metadata filter table
819
820
821
822 uint32
823
824
826
827
829
831
832
833 IFE
834
835 This LFB describes IFE connectivity parameterization
836
837 1.0
839
841
842 EgressInGroup
843
844 The input port group of the egress side.
845 It expects any type of Ethernet frame.
846
847
848
849 [PacketAny]
850
851
852
854
855 IngressInGroup
856
857 The input port group of the ingress side.
858 It expects an interFE encapsulated Ethernet frame.
859
860
861
862 [InterFEFrame]
863
864
865
866
868
870
871 OUT1
872
873 The output port of the egress side.
874
875
876
877 [InterFEFrame]
878
879
880
882
883 OUT2
884
885 The output port of the Ingress side.
886
887
888
889 [PacketAny]
890
891
892
894
895 EXCEPTIONOUT
896
897 The exception handling path
898
899
900
901 [PacketAny]
902
903
904 [ExceptionID]
905
906
907
909
911
913
914 IFETable
915
916 the table of all InterFE relations
917
918
919 IFEInfo
920
921
923
924 IFEStats
925
926 the stats corresponding to the IFETable table
927
928 bstats
929
931
933
934
936
938 Figure 8: Inter-FE LFB XML
940 7. Acknowledgements
942 The authors would like to thank Joel Halpern and Dave Hood for the
943 stimulating discussions. Evangelos Haleplidis shepherded and
944 contributed to improving this document. Alia Atlas was the AD
945 sponsor of this document and did a tremendous job of critiquing it.
946 The authors are grateful to Joel Halpern and Sue Hares in their roles
947 as the Routing Area reviewers in shaping the content of this
948 document. David Black put a lot of effort in making sure congestion
949 control considerations are sane. Russ Housley did the Gen-ART review
950 and Joe Touch did the TSV area. Shucheng LIU (Will) did the OPS
951 review. Suresh Krishnan helped us provide clarity during the IESG
952 review. The authors are appreciative of the efforts Stephen Farrell
953 put in fixing the security section.
955 8. IANA Considerations
957 This memo includes one IANA request within the registry https://
958 www.iana.org/assignments/forces
959 The request is for the sub-registry "Logical Functional Block (LFB)
960 Class Names and Class Identifiers" to request for the reservation of
961 LFB class name IFE with LFB classid 18 with version 1.0.
963 +--------------+---------+---------+-------------------+------------+
964 | LFB Class | LFB | LFB | Description | Reference |
965 | Identifier | Class | Version | | |
966 | | Name | | | |
967 +--------------+---------+---------+-------------------+------------+
968 | 18 | IFE | 1.0 | An IFE LFB to | This |
969 | | | | standardize | document |
970 | | | | inter-FE LFB for | |
971 | | | | ForCES Network | |
972 | | | | Elements | |
973 +--------------+---------+---------+-------------------+------------+
975 Logical Functional Block (LFB) Class Names and Class Identifiers
977 9. IEEE Assignment Considerations
979 This memo includes a request for a new ethernet protocol type as
980 described in Section 5.2.
982 10. Security Considerations
984 The FEs involved in the Inter-FE LFB belong to the same Network
985 Device (NE) and are within the scope of a single administrative
986 Ethernet LAN private network. While trust of policy in the control
987 and its treatment in the datapath exists already, an Inter-FE LFB
988 implementation SHOULD support security services provided by Media
989 Access Control Security(MACsec)[ieee8021ae]. MACsec is not currently
990 sufficiently widely deployed in traditional packet processing
991 hardware although present in newer versions of the Linux kernel
992 (which will be widely deployed) [linux-macsec]. Over time we would
993 expect that most FEs will be able to support MACsec.
995 MACsec provides security services such as message authentication
996 service and optional confidentiality service. The services can be
997 configured manually or automatically using MACsec Key Agreement(MKA)
998 over IEEE 802.1x [ieee8021x] Extensible Authentication Protocol (EAP)
999 framework. It is expected FE implementations are going to start with
1000 shared keys configured from the control plane but progress to
1001 automated key management.
1003 The following are the MACsec security mechanisms that need to be in
1004 place for the InterFE LFB:
1006 o Security mechanisms are NE-wide for all FEs. Once the security is
1007 turned on depending upon the chosen security level
1008 (Authentication, Confidentiality), it will be in effect for the
1009 inter-FE LFB for the entire duration of the session.
1011 o An operator SHOULD configure the same security policies for all
1012 participating FEs in the NE cluster. This will ensure uniform
1013 operations and avoid unnecessary complexity in policy
1014 configuration. In other words, the Security Association
1015 Keys(SAKs) should be pre-shared. When using MKA, FEs must
1016 identify themselves with a shared Connectivity Association Key
1017 (CAK) and Connectivity Association Key Name (CKN). EAP-TLS SHOULD
1018 be used as the EAP method.
1020 o An operator SHOULD configure the strict validation mode i.e all
1021 non-protected, invalid or non-verifiable frames MUST be dropped.
1023 It should be noted that given the above choices, if an FE is
1024 compromised, an entity running on the FE would be able to fake inter-
1025 FE or modify its content causing bad outcomes.
1027 11. References
1029 11.1. Normative References
1031 [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed.,
1032 Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and
1033 J. Halpern, "Forwarding and Control Element Separation
1034 (ForCES) Protocol Specification", RFC 5810, DOI 10.17487/
1035 RFC5810, March 2010,
1036 .
1038 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
1039 Layer (TML) for the Forwarding and Control Element
1040 Separation (ForCES) Protocol", RFC 5811, DOI 10.17487/
1041 RFC5811, March 2010,
1042 .
1044 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
1045 Element Separation (ForCES) Forwarding Element Model", RFC
1046 5812, DOI 10.17487/RFC5812, March 2010,
1047 .
1049 [RFC7391] Hadi Salim, J., "Forwarding and Control Element Separation
1050 (ForCES) Protocol Extensions", RFC 7391, DOI 10.17487/
1051 RFC7391, October 2014,
1052 .
1054 [RFC7408] Haleplidis, E., "Forwarding and Control Element Separation
1055 (ForCES) Model Extension", RFC 7408, DOI 10.17487/RFC7408,
1056 November 2014, .
1058 [draft-ietf-tsvwg-rfc5405bis]
1059 Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
1060 Guidelines", Nov 2015, .
1063 [ieee8021ae]
1064 , "IEEE Standard for Local and metropolitan area networks
1065 Media Access Control (MAC) Security", IEEE 802.1AE-2006,
1066 Aug 2006.
1068 [ieee8021x]
1069 , "IEEE standard for local and metropolitan area networks
1070 - port-based network access control.", IEEE 802.1X-2010,
1071 2010.
1073 11.2. Informative References
1075 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1076 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
1077 RFC2119, March 1997,
1078 .
1080 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
1081 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
1082 December 1998, .
1084 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
1085 "Forwarding and Control Element Separation (ForCES)
1086 Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004,
1087 .
1089 [RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
1090 Halpern, "Forwarding and Control Element Separation
1091 (ForCES) Logical Function Block (LFB) Library", RFC 6956,
1092 DOI 10.17487/RFC6956, June 2013,
1093 .
1095 [brcm-higig]
1096 , "HiGig",
1097 .
1099 [circuit-b]
1100 Fairhurst, G., "Network Transport Circuit Breakers", Feb
1101 2016, .
1104 [linux-macsec]
1105 Dubroca, S., "MACsec: Encryption for the wired LAN",
1106 netdev 11, Feb 2016.
1108 [linux-tc]
1109 Hadi Salim, J., "Linux Traffic Control Classifier-Action
1110 Subsystem Architecture", netdev 01, Feb 2015.
1112 [tc-ife] Hadi Salim, J. and D. Joachimpillai, "Distributing Linux
1113 Traffic Control Classifier-Action Subsystem", netdev 01,
1114 Feb 2015.
1116 [vxlan-udp]
1117 , "iproute2 and kernel code (drivers/net/vxlan.c)",
1118 .
1120 Authors' Addresses
1122 Damascane M. Joachimpillai
1123 Verizon
1124 60 Sylvan Rd
1125 Waltham, Mass. 02451
1126 USA
1128 Email: damascene.joachimpillai@verizon.com
1130 Jamal Hadi Salim
1131 Mojatatu Networks
1132 Suite 200, 15 Fitzgerald Rd.
1133 Ottawa, Ontario K2H 9G1
1134 Canada
1136 Email: hadi@mojatatu.com