idnits 2.17.1
draft-ietf-forces-interfelfb-01.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 6, 2015) is 3339 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)
** Downref: Normative reference to an Informational RFC: RFC 3746
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
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: September 7, 2015 Mojatatu Networks
6 March 6, 2015
8 ForCES Inter-FE LFB
9 draft-ietf-forces-interfelfb-01
11 Abstract
13 This document describes extending the ForCES LFB topology across FEs
14 i.e inter-FE connectivity without needing any changes to the ForCES
15 specification by defining the Inter-FE LFB. The Inter-FE LFB
16 provides ability to pass data, metadata and exceptions across FEs.
17 The document describes a generic way to transport the mentioned
18 details but focuses on ethernet transport.
20 Status of this Memo
22 This Internet-Draft is submitted in full conformance with the
23 provisions of BCP 78 and BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF). Note that other groups may also distribute
27 working documents as Internet-Drafts. The list of current Internet-
28 Drafts is at http://datatracker.ietf.org/drafts/current/.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 This Internet-Draft will expire on September 7, 2015.
37 Copyright Notice
39 Copyright (c) 2015 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (http://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
52 Table of Contents
54 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
56 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 3. Problem Scope And Use Cases . . . . . . . . . . . . . . . . . 4
59 3.1. Basic Router . . . . . . . . . . . . . . . . . . . . . . . 4
60 3.1.1. Distributing The LFB Topology . . . . . . . . . . . . 6
61 3.2. Arbitrary Network Function . . . . . . . . . . . . . . . . 7
62 3.2.1. Distributing The Arbitrary Network Function . . . . . 8
63 4. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 9
64 4.1. Inserting The Inter-FE LFB . . . . . . . . . . . . . . . . 9
65 5. Generic Inter-FE connectivity . . . . . . . . . . . . . . . . 11
66 5.1. Inter-FE Ethernet Connectivity . . . . . . . . . . . . . . 13
67 5.1.1. Inter-FE Ethernet Connectivity Issues . . . . . . . . 15
68 6. Detailed Description of the Ethernet inter-FE LFB . . . . . . 16
69 6.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 16
70 6.1.1. Egress Processing . . . . . . . . . . . . . . . . . . 17
71 6.1.2. Ingress Processing . . . . . . . . . . . . . . . . . . 18
72 6.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 19
73 6.3. Inter-FE LFB XML Model . . . . . . . . . . . . . . . . . . 19
74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
76 9. IEEE Assignment Considerations . . . . . . . . . . . . . . . . 24
77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
80 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
83 1. Terminology and Conventions
85 1.1. Requirements Language
87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
89 document are to be interpreted as described in [RFC2119].
91 1.2. Definitions
93 This document reiterates the terminology defined in several ForCES
94 documents [RFC3746], [RFC5810], [RFC5811], and [RFC5812] for the sake
95 of contextual clarity.
97 Control Engine (CE)
99 Forwarding Engine (FE)
101 FE Model
103 LFB (Logical Functional Block) Class (or type)
105 LFB Instance
107 LFB Model
109 LFB Metadata
111 ForCES Component
113 LFB Component
115 ForCES Protocol Layer (ForCES PL)
117 ForCES Protocol Transport Mapping Layer (ForCES TML)
119 2. Introduction
121 In the ForCES architecture, a packet service can be modelled by
122 composing a graph of one or more LFB instances. The reader is
123 referred to the details in the ForCES Model [RFC5812].
125 The FEObject LFB capabilities in the ForCES Model [RFC5812] define
126 component ModifiableLFBTopology which, when advertised by the FE,
127 implies that the advertising FE is capable of allowing creation and
128 modification of LFB graph(s) by the control plane. Details on how a
129 graph of LFB class instances can be created can be derived by the
130 control plane by looking at the FE's FEObject LFB class table
131 component SupportedLFBs. The SupportedLFBs table contains
132 information about each LFB class that the FE supports. For each LFB
133 class supported, details are provided on how the supported LFB class
134 may be connected to other LFB classes. The SupportedLFBs table
135 describes which LFB class a specified LFB class may succeed or
136 precede in an LFB class instance topology. Each link connecting two
137 LFB class instances is described in the LFBLinkType dataTypeDef and
138 has sufficient details to identify precisely the end points of a link
139 of a service graph.
141 The CE may therefore create a packet service by describing an LFB
142 instance graph connection; this is achieved by updating the FEOBject
143 LFBTopology table.
145 Often there are requirements for the packet service graph to cross FE
146 boundaries. This could be from a desire to scale the service or need
147 to interact with LFBs which reside in a separate FE (eg lookaside
148 interface to a shared TCAM, an interconnected chip, or as coarse
149 grained functionality as an external NAT FE box being part of the
150 service graph etc).
152 Given that the ForCES inter-LFB architecture calls out for ability to
153 pass metadata between LFBs, it is imperative therefore to define
154 mechanisms to extend that existing feature and allow passing the
155 metadata between LFBs across FEs.
157 This document describes extending the LFB topology across FEs i.e
158 inter-FE connectivity without needing any changes to the ForCES
159 definitions. It focusses on using Ethernet as the interconnection as
160 a starting point while leaving room for other protocols (such as
161 directly on top of IP, UDP, VXLAN, etc) to be addressed by other
162 future documents.
164 3. Problem Scope And Use Cases
166 The scope of this document is to solve the challenge of passing
167 ForCES defined metadata and exceptions across FEs (be they physical
168 or virtual). To illustrate the problem scope we present two use
169 cases where we start with a single FE running all the functionality
170 then split it into multiple FEs.
172 3.1. Basic Router
174 A sample LFB topology Figure 1 demonstrates a service graph for
175 delivering basic IPV4 forwarding service within one FE. For the
176 purpose of illustration, the diagram shows LFB classes as graph nodes
177 instead of multiple LFB class instances.
179 Since the illustration is meant only as an exercise to showcase how
180 data and metadata are sent down or upstream on a graph of LFBs, it
181 abstracts out any ports in both directions and talks about a generic
182 ingress and egress LFB. Again, for illustration purposes, the
183 diagram does not show exception or error paths. Also left out are
184 details on Reverse Path Filtering, ECMP, multicast handling etc. In
185 other words, this is not meant to be a complete description of an
186 IPV4 forwarding application; for a more complete example, please
187 refer to the LFBlib document [RFC6956].
189 The output of the ingress LFB(s) coming into the IPv4 Validator LFB
190 will have both the IPV4 packets and, depending on the implementation,
191 a variety of ingress metadata such as offsets into the different
192 headers, any classification metadata, physical and virtual ports
193 encountered, tunnelling information etc. These metadata are lumped
194 together as "ingress metadata".
196 Once the IPV4 validator vets the packet (example ensures that no
197 expired TTL etc), it feeds the packet and inherited metadata into the
198 IPV4 unicast LPM LFB.
200 +----+
201 | |
202 IPV4 pkt | | IPV4 pkt +-----+ +---+
203 +------------->| +------------->| | | |
204 | + ingress | | + ingress |IPv4 | IPV4 pkt | |
205 | metadata | | metadata |Ucast+------------>| +--+
206 | +----+ |LPM | + ingress | | |
207 +-+-+ IPv4 +-----+ + NHinfo +---+ |
208 | | Validator metadata IPv4 |
209 | | LFB NextHop|
210 | | LFB |
211 | | |
212 | | IPV4 pkt |
213 | | + {ingress |
214 +---+ + NHdetails}
215 Ingress metadata |
216 LFB +--------+ |
217 | Egress | |
218 <--+ |<-----------------+
219 | LFB |
220 +--------+
222 Figure 1: Basic IPV4 packet service LFB topology
224 The IPV4 unicast LPM LFB does a longest prefix match lookup on the
225 IPV4 FIB using the destination IP address as a search key. The
226 result is typically a next hop selector which is passed downstream as
227 metadata.
229 The Nexthop LFB receives the IPv4 packet with an associated next hop
230 info metadata. The NextHop LFB consumes the NH info metadata and
231 derives from it a table index to look up the next hop table in order
232 to find the appropriate egress information. The lookup result is
233 used to build the next hop details to be used downstream on the
234 egress. This information may include any source and destination
235 information (MAC address to use, if ethernet;) as well egress ports.
236 [Note: It is also at this LFB where typically the forwarding TTL
237 decrement and IP checksum recalculation occurs.]
239 The details of the egress LFB are considered out of scope for this
240 discussion. Suffice it is to say that somewhere within or beyond the
241 Egress LFB the IPV4 packet will be sent out a port (ethernet, virtual
242 or physical etc).
244 3.1.1. Distributing The LFB Topology
246 Figure 2 demonstrates one way the router LFB topology in Figure 1 may
247 be split across two FEs (eg two ASICs). Figure 2 shows the LFB
248 topology split across FEs after the IPV4 unicast LPM LFB.
250 FE1
251 +-------------------------------------------------------------+
252 | +----+ |
253 | +----------+ | | |
254 | | Ingress | IPV4 pkt | | IPV4 pkt +-----+ |
255 | | LFB +-------------->| +------------->| | |
256 | | | + ingress | | + ingress |IPv4 | |
257 | +----------+ metadata | | metadata |Ucast| |
258 | ^ +----+ |LPM | |
259 | | IPv4 +--+--+ |
260 | | Validator | |
261 | LFB | |
262 +---------------------------------------------------|---------+
263 |
264 IPv4 packet +
265 {ingress + NHinfo}
266 metadata
267 FE2 |
268 +---------------------------------------------------|---------+
269 | V |
270 | +--------+ +--------+ |
271 | | Egress | IPV4 packet | IPV4 | |
272 | <-----+ LFB |<----------------------+NextHop | |
273 | | |{ingress + NHdetails} | LFB | |
274 | +--------+ metadata +--------+ |
275 +-------------------------------------------------------------+
277 Figure 2: Split IPV4 packet service LFB topology
279 Some proprietary inter-connect (example Broadcom Higig over XAUI
280 [brcm-higig]) are known to exist to carry both the IPV4 packet and
281 the related metadata between the IPV4 Unicast LFB and IPV4 NextHop
282 LFB across the two FEs.
284 The purpose of the inter-FE LFB is to define standard mechanisms for
285 interconnecting FEs and for that reason we are not going to touch
286 anymore on proprietary chip-chip interconnects other than state the
287 fact they exist and that it is feasible to have translation to and
288 from proprietary approaches. The document focus is the FE-FE
289 interconnect where the FE could be physical or virtual and the
290 interconnecting technology runs a standard protocol such as ethernet,
291 IP or other protocols on top of IP.
293 3.2. Arbitrary Network Function
295 In this section we show an example of an arbitrary network function
296 which is more coarse grained in terms of functionality. Each Network
297 function may constitute more than one LFB.
299 FE1
300 +-------------------------------------------------------------+
301 | +----+ |
302 | +----------+ | | |
303 | | Network | pkt |NF2 | pkt +-----+ |
304 | | Function +-------------->| +------------->| | |
305 | | 1 | + NF1 | | + NF1/2 |NF3 | |
306 | +----------+ metadata | | metadata | | |
307 | ^ +----+ | | |
308 | | +--+--+ |
309 | | | |
310 | | |
311 +---------------------------------------------------|---------+
312 V
314 Figure 3: A Network Function Service Chain within one FE
316 The setup in Figure 3 is a typical of most packet processing boxes
317 where we have functions like DPI, NAT, Routing, etc connected in such
318 a topology to deliver a packet processing service to flows.
320 3.2.1. Distributing The Arbitrary Network Function
322 The setup in Figure 3 can be split out across 3 FEs instead as
323 demonstrated in Figure 4. This could be motivated by scale out
324 reasons or because different vendors provide different functionality
325 which is plugged-in to provide such functionality. The end result is
326 to have the same packet service delivered to the different flows
327 passing through.
329 FE1 FE2
330 +----------+ +----+ FE3
331 | Network | pkt |NF2 | pkt +-----+
332 | Function +-------------->| +------------->| |
333 | 1 | + NF1 | | + NF1/2 |NF3 |
334 +----------+ metadata | | metadata | |
335 ^ +----+ | |
336 | +--+--+
337 |
338 V
340 Figure 4: A Network Function Service Chain Distributed Across
341 Multiple FEs
343 4. Proposal Overview
345 We address the inter-FE connectivity requirements by proposing the
346 inter-FE LFB class. Using a standard LFB class definition implies no
347 change to the basic ForCES architecture in the form of the core LFBs
348 (FE Protocol or Object LFBs). This design choice was made after
349 considering an alternative approach that would have required changes
350 to both the FE Object capabilities (SupportedLFBs) as well
351 LFBTopology component to describe the inter-FE connectivity
352 capabilities as well as runtime topology of the LFB instances.
354 4.1. Inserting The Inter-FE LFB
356 The distributed LFB topology described in Figure 2 is re-illustrated
357 in Figure 5 to show the topology location where the inter-FE LFB
358 would fit in.
360 FE1
361 +-------------------------------------------------------------+
362 | +----------+ +----+ |
363 | | Ingress | IPV4 pkt | | IPV4 pkt +-----+ |
364 | | LFB +-------------->| +------------->| | |
365 | | | + ingress | | + ingress |IPv4 | |
366 | +----------+ metadata | | metadata |Ucast| |
367 | ^ +----+ |LPM | |
368 | | IPv4 +--+--+ |
369 | | Validator | |
370 | | LFB | |
371 | | IPv4 pkt + metadata |
372 | | {ingress + NHinfo + InterFEid}|
373 | | | |
374 | +----V----+ |
375 | | InterFE | |
376 | | LFB | |
377 | +----+----+ |
378 +---------------------------------------------------|---------+
379 |
380 IPv4 packet and metadata
381 {ingress + NHinfo + Inter FE info}
382 FE2 |
383 +---------------------------------------------------|---------+
384 | +----V----+ |
385 | | InterFE | |
386 | | LFB | |
387 | +----+----+ |
388 | | |
389 | IPv4 pkt + metadata |
390 | {ingress + NHinfo} |
391 | | |
392 | +--------+ +----V---+ |
393 | | Egress | IPV4 packet | IPV4 | |
394 | <-----+ LFB |<----------------------+NextHop | |
395 | | |{ingress + NHdetails} | LFB | |
396 | +--------+ metadata +--------+ |
397 +-------------------------------------------------------------+
399 Figure 5: Split IPV4 forwarding service with Inter-FE LFB
401 As can be observed in Figure 5, the same details passed between IPV4
402 unicast LPM LFB and the IPV4 NH LFB are passed to the egress side of
403 the Inter-FE LFB. In addition an index for the inter-FE LFB
404 (interFEid) is passed as metadata.
406 The egress of the inter-FE LFB uses the received Inter-FE index
407 (InterFEid metadata) to select details for encapsulation when sending
408 messages towards the selected neighboring FE. These details will
409 include what to communicate as the source and destination FEID; in
410 addition the original metadata and any exception IDs may be passed
411 along with the original IPV4 packet.
413 On the ingress side of the inter-FE LFB the received packet and its
414 associated details are used to decide the packet graph continuation.
415 This includes what of the of the original metadata and exception IDs
416 to restore and what next LFB class instance to continue processing
417 on. In the illustrated case above, an IPV4 Nexthop LFB is selected
418 and metadata is passed on to it.
420 The ingress side of the inter-FE LFB consumes some of the information
421 passed (eg the destination FEID) and passes on the IPV4 packet
422 alongside with the ingress + NHinfo metadata to the IPV4 NextHop LFB
423 as was done earlier in both Figure 1 and Figure 2.
425 5. Generic Inter-FE connectivity
427 In this section we describe the generic encapsulation format in
428 Figure 6 as extended from the ForCES redirect packet format. We
429 intend for the described encapsulation to be a generic guideline of
430 the different needed fields to be made available by any used
431 transport for inter-FE LFB connectivity. We expect that for any
432 transport mechanism used, a description of how the different fields
433 will be encapsulated to be correlated to the information described in
434 Figure 6. The goal of this document is to provide ethernet
435 encapsulation, and to that end in Section 5.1 we illustrate how we
436 use the guidelines provided in this section to describe the fit for
437 inter-FE LFB interfacing over ethernet.
439 +-- Main ForCES header
440 | |
441 | +---- msg type = REDIRECT
442 | +---- Destination FEID
443 | +---- Source FEID
444 | +---- NEID (first word of Correlator)
445 |
446 +-- T = ExceptionID-TLV
447 | |
448 | +-- +-Exception Data ILV (I = exceptionID , L= length)
449 | | | |
450 | | | +----- V= Metadata value
451 | . |
452 | . |
453 | . +-Exception Data ILV
454 .
455 |
456 +- T = METADATA-TLV
457 | |
458 | +-- +-Meta Data ILV (I = metaid, L= length)
459 | | | |
460 | | | +----- V= Metadata value
461 | . |
462 | . |
463 | . +-Meta Data ILV
464 .
465 +- T = REDIRECTDATA-TLV
466 |
467 +-- Redirected packet Data
469 Figure 6: Packet format suggestion
471 o The ForCES main header as described in RFC5810 is used as a fixed
472 header to describe the Inter-FE encapsulation.
474 * The Source FEID field is mapped to the originating FE and the
475 destination FEID is mapped to the destination FEID.
477 * The first 32 bits of the correlator field are used to carry the
478 NEID. The 32-bit NEID defaults to 0.
480 o The ExceptionID TLV carries one or more exception IDs within ILVs.
481 The I in the ILV carries a globally defined exceptionID as per-
482 ForCES specification defined by IANA. This TLV is new to ForCES
483 and sits in the global ForCES TLV namespace.
485 o The METADATA and REDIRECTDATA TLV encapsulations are taken
486 directly from [RFC5810] section 7.9.
488 It is expected that a variety of transport encapsulations would be
489 applicable to carry the format described in Figure 6. In such a
490 case, a description of a mapping to interpret the inter-FE details
491 and translate into proprietary or legacy formatting would need to be
492 defined. For any mapping towards these definitions a different
493 document to describe the mapping, one per transport, is expected to
494 be defined.
496 5.1. Inter-FE Ethernet Connectivity
498 In this document, we describe a format that is to be used over
499 Ethernet. An existing implementation of this specification on top of
500 Linux Traffic Control [linux-tc] is described in [tc-ife].
502 The following describes the mapping from Figure 6 to ethernet wire
503 encapsulation illustrated in Figure 7.
505 o When an NE tag is needed, a VLAN tag will be used. Note: that the
506 NEID as per Figure 6 is described as being 32 bits while a vlan
507 tag is 12 bits. It is however thought to be sufficient to use 12
508 bits within the scope of a LAN NE cluster.
510 o An ethernet type will be used to imply that a wire format is
511 carrying an inter-FE LFB packet. The ethernet type to be used is
512 0xFEFE (XXX: Note to editor, to be updated when issued by IEEE
513 Standards Association).
515 o The destination FEID will be mapped to the destination MAC address
516 of the target FEID.
518 o The source FEID will be mapped to the source MAC address of the
519 originating FEID.
521 o In this version of the specification, we only focus on data and
522 metadata. Therefore we are not going to describe how to carry the
523 ExceptionID information (future versions may). We are also not
524 going to use METADATA-TLV or REDIRECTDATA-TLV in order to save
525 shave off some overhead bytes. Figure 7 describes the payload.
527 0 1 2 3
528 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
529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
530 | Outer Destination MAC Address (Destination FEID) |
531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
532 | Outer Destination MAC Address | Outer Source MAC Address |
533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
534 | Outer Source MAC Address (Source FEID) |
535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
536 | Optional 802.1Q info (NEID) | Inter-FE ethertype |
537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
538 | Metadata length | TLV encoded Metadata |
539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
540 | TLV encoded Metadata ~~~..............~~ |
541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
542 | Original Ethernet payload ~~................~~ |
543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
545 Figure 7: Packet format suggestion
547 An outer Ethernet header is introduced to carry the information on
548 Destination FEID, Source FEID and optional NEID.
550 o The Outer Destination MAC Address carries the Destination FEID
551 identification.
553 o Outer Source MAC Address carries the Source FEID identification.
555 o When an NEID is needed, an optional 802.1Q is carried with 12-bit
556 VLANid representing the NEID.
558 o The ethernet type is used to identify the frame as inter-FE LFB
559 type. Ethertype 0xFEFE is to be used (XXX: Note, to editor update
560 when available).
562 o The 16-bit metadata length is used to described the total encoded
563 metadata length (including the 16 bits used to encode the metadata
564 length).
566 o One or more TLV encoded metadatum follows the metadata length
567 field. The TLV type identifies the Metadata id. ForCES IANA-
568 defined Metadata ids will be used. We recognize that using a 16
569 bit TLV restricts the metadata id to 16 bits instead of ForCES
570 define space of 32 bits. However, at the time of publication we
571 believe this is sufficient to carry all the info we need and
572 approach taken would save us 4 bytes per Metadatum transferred.
574 o The original ethernet payload is appended at the end of the
575 metadata as shown.
577 5.1.1. Inter-FE Ethernet Connectivity Issues
579 There are several issues that may arise due to using direct ethernet
580 encapsulation.
582 o Because we are adding data to existing ethernet frames, MTU issues
583 may arise. We recommend:
585 * To use large MTUs when possible (example with jumbo frames).
587 * Limit the amount of metadata that could be transmitted; our
588 definition allows for filtering of which metadata is to be
589 encapsulated in the frame. We recommend implementing this by
590 setting the egress port MTU to allow space for maximum size of
591 the metadata total size you wish to allow between FEs. In such
592 a setup, the port is configured to "lie" to the upper layers by
593 claiming to have a lower MTU than it is capable of. MTU
594 setting can be achieved by ForCES control of the port LFB(or
595 other config). In essence, the control plane making a decision
596 for the MTU settings of the egress port is implicitly deciding
597 how much metadata will be allowed.
599 o The frame may be dropped if there is congestion on the receiving
600 FE side. One approach to mitigate this issue is to make sure that
601 inter-FE LFB frames receive the highest priority treatment when
602 scheduled on the wire. Typically protocols that tunnel in the
603 middle box do not care and depend on the packet originator to
604 resend if the originator cares about reliability. We do not
605 expect to be any different.
607 o While we expect to use a unique IEEE-issued ethertype for the
608 inter-FE traffic, we use lessons learnt from VXLAN deployment xref
609 to be more flexible on the settings of the ethertype value used.
610 We make the ether type an LFB read-write component. Linux VXLAN
611 implementation uses UDP port 8472 because the deployment happened
612 much earlier than the point of RFC publication where the IANA
613 assigned udp port issued was 4789 [vxlan-udp]. For this reason we
614 make it possible to define at control time what ethertype to use
615 and default to the IEEE issued ethertype. We justify this by
616 assuming that a given ForCES NE is likely to be owned by a single
617 organization and that the organization's CE(or CE cluster) could
618 program all participating FEs via the inter-FE LFB (described in
619 this document) to recognize a private ethernet type used for
620 inter-LFB traffic (possibly those defined as available for private
621 use by the IEEE, namely: IDs 0x88B5 and 0x88B6)
623 6. Detailed Description of the Ethernet inter-FE LFB
625 The ethernet inter-FE LFB has two LFB input ports and three LFB
626 output ports.
628 +-----------------+
629 Inter-FE LFB | |
630 Encapsulated | OUT2+--> decapsulated Packet + metadata
631 -------------->|IN2 |
632 Packet | |
633 | |
634 raw Packet + | OUT1+--> encapsulated Packet
635 -------------->|IN1 |
636 Metadata | |
637 | EXCEPTIONOUT +--> ExceptionID, packet + metadata
638 | |
639 +-----------------+
641 Figure 8: Inter-FE LFB
643 6.1. Data Handling
645 The Inter-FE LFB can be positioned at the egress of a source FE. In
646 such a case an Inter-FE LFB instance receives via port IN1, raw
647 packet and metadata IDs from the preceding LFB instance. The
648 InterFEid metadatum MAY be present on the incoming raw data. The
649 processed encapsulated packet will go out on either LFB port OUT1 to
650 a downstream LFB or EXCEPTIONOUT port in the case of a failure.
652 The Inter-FE LFB can be positioned at the ingress of a receiving FE.
653 In such a case an Inter-FE LFB receives, via port IN2, an
654 encapsulated packet. Successful processing of the packet will result
655 in a raw packet with associated metadata IDs going downstream to an
656 LFB connected on OUT2. On failure the data is sent out EXCEPTIONOUT.
658 The Inter-FE LFB may use the InterFEid metadatum on egress of an FE
659 to lookup the IFETable table. The interFEid in such a case will be
660 generated by an upstream LFB instance (i.e one preceding the Inter-FE
661 LFB). The output result constitutes a matched table row which has
662 the InterFEinfo details i.e. the tuple {NEID,Destination FEID,Source
663 FEID, inter FE type, metafilters}. The metafilters lists define
664 which Metadatum are to be passed to the neighboring FE.
666 The component names used in describing processing are defined in
667 Section 6.2
669 6.1.1. Egress Processing
671 The egress Inter-FE LFB will receive an ethernet frame and
672 accompanying metadatum (including optionally the InterFEid metadatum)
673 at LFB port IN1. The ethernet frame may be 802.1Q tagged.
675 The InterFEid may be used to lookup IFETable table. If lookup is
676 successful, the inter-FE LFB will perform the following actions using
677 the resulting tuple:
679 o Increment statistics for packet and byte count observed.
681 o Walk each packet metadatum and apply against the relevant
682 MetaFilterList. If no legitimate metadata is found that needs to
683 be passed downstream then the processing stops and the packet is
684 allowed through as is.
686 o Check that the additional overhead of the outer header and
687 encapsulated metadata will not exceed MTU. If it does, increment
688 the error packet count statistics and return allowing the packet
689 to pass through.
691 o create the outer ethernet header which is a duplicate of the
692 incoming frame's ethernet header. The outer ethernet header may
693 have an optional 802.1q header (if one was included in the
694 original frame).
696 o If the NEID field is present (not 0) and the original header had a
697 vlan tag, replace the vlan tag on the outer header with the value
698 from the matched NEID field. If the NEID field is present (not 0)
699 and the original header did not have a vlan tag, create one that
700 matches the NEID field and appropriately add it to the outer
701 header. If the NEID field is absent or 0, do nothing.
703 o If the optional DSTFE is present, set the Destination MAC address
704 of the outer header with value found in the DSTFE field. When
705 absent, then the inner destination MAC address is used (at this
706 point already copied).
708 o If the optional SRCFE is present, set the Source MAC address of
709 the outer header with value found in the SRCFE field. If SRCFE is
710 absent then the inner source MAC address is used (at this point
711 already copied).
713 o If the optional IFETYPE is present, set the outer ethernet type to
714 the value found in IFETYPE. If IFETYPE is absent then the
715 standard ethernet type is used (XXX: Note to editor, to be
716 updated).
718 o encapsulate each allowed metadatum in a TLV. Use the Metaid as
719 the "type" field in the TLV header. The TLV should be aligned to
720 32 bits. This means you may need to add padding of zeroes to
721 ensure alignment.
723 o Update the Metadata length to the sum of each TLV's space + 2
724 bytes (for the Metadata length field 16 bit space).
726 The resulting packet is sent to the next LFB instance connected to
727 the OUT1 LFB-port; typically a port LFB.
729 In the case of a failed lookup or a zero-value InterFEid, (or absence
730 of InterFEid when needed by the implementation) the packet is sent
731 out unchanged via the OUT1 LFB Class instance port (typically towards
732 a Port LFB).
734 6.1.2. Ingress Processing
736 An inter-FE LFB packet is recognized by looking at the etherype
737 received on LFB instance port IN2. The IFETable table may be
738 optionally utilized to provide metadata filters.
740 o Increment statistics for packet and byte count observed.
742 o Look at the metadata length field and walk the packet data
743 extracting from the TLVs the metadata values. For each metadatum
744 extracted, the metaid is compared against the relevant IFETable
745 row metafilter list. If the metadatum is recognized, and is
746 allowed by the filter the corresponding implementation metadatum
747 field is set. If an unknown metadatum id is encountered, or if
748 the metaid is not found in the option allowed filter list the
749 implementation is expected to ignore it, increment the packet
750 error statistic and proceed processing other metadatum.
752 o Upon completion of processing all the metadata, the inter-FE LFB
753 instance resets the header to point to the original (inner)
754 ethernet header i.e skips the IFE header information. At this
755 point the the original ethernet frame that was passed to the
756 egress Inter-FE LFB at the source FE is reconstructed. This data
757 is then passed along with the reconstructed metadata downstream to
758 the next LFB instance in the graph.
760 In the case of processing failure of either ingress or egress
761 positioning of the LFB, the packet and metadata are sent out the
762 EXCEPTIONOUT LFB port with appropriate error id. Note that the
763 EXCEPTIONOUT LFB port is merely an abstraction and implementation may
764 in fact drop packets as described above.
766 6.2. Components
768 There are two LFB component populated by the CE.
770 The CE optionally programs LFB instances in a service graph that
771 require inter-FE connectivity with InterFEid values to correspond to
772 the inter-FE LFB IFETable table entries to use.
774 The first component is an array known as the IFETable table. The
775 array rows are made up of IFEInfo structure. The IFEInfo structure
776 constitutes: optional NEID, optional IFETYPE, optional Destination
777 FEID(DSTFE), optional Source FEID (SRCFE), optional array of allowed
778 Metaids (MetaFilterList). The table is looked up by a 32 bit index
779 passed from an upstream LFB class instance in the form of InterFEid
780 metadatum.
782 The second component(ID 2) is IFEStats table which carries the basic
783 stats structure bstats. The table index value used to lookup this
784 table is the same one as in IFETable table; in other words for a
785 table row index 10 in the IFETable table, its corresponding stats
786 will be found in row index of the IFEStats table.
788 6.3. Inter-FE LFB XML Model
790
793
795
796 EthernetAny
797 Packet with any Ethernet type
798
799
800 InterFEFrame
801
802 Packet with an encapsulate IFE Ethernet type
803
804
806
808
810
811 bstats
812 Basic stats
814
815
816 bytes
817 The total number of bytes seen
818 uint64
819
821
822 packets
823 The total number of packets seen
824 uint32
825
827
828 errors
829 The total number of packets with errors
830 uint32
831
832
834
836
837 IFEInfo
838 Describing IFE table row Information
839
840
841 NEID
842
843 The VLAN Id 12 bits part of the 802.1q TCI field.
844
845
846 uint16
847
848
849 IFETYPE
850
851 the ethernet type to be used for outgoing IFE frame
852
853
854 uint16
855
856
857 DSTFE
858
859 the destination MAC address of destination FE
860
861
862 byte[6]
863
864
865 SRCFE
866
867 the source MAC address used for the source FE
868
869
870 byte[6]
871
872
873 MetaFilterList
874
875 the allowed metadata filter table
876
877
878
879 uint32
880
881
883
884
886
888
889
890 InterFEid
891
892 Metadata identifying the index of the NexFE table
893
894 16
895 uint32
896
897
899
900
901 IFE
902
903 This LFB describes IFE connectivity parameterization
904
905 1.0
907
908
909 IN1
910
911 The input port of the egress side.
912 It expects any type of Ethernet frame.
913
914
915
916 [EthernetAny]
917
918
919
920
921 IN2
922
923 The input port of the ingress side.
924 It expects an inter-FE encapsulated Ethernet frame
925 with associated metadata.
926
927
928
929 [InterFEFrame]
930
931
932 [InterFEid]
933
934
935
937
939
941
942 OUT1
943
944 The output port of the egress side.
945
946
947
948 [InterFEFrame]
949
950
951 [InterFEid]
952
953
954
955
956 OUT2
957
958 The output port of the Ingress side.
959
960
961
962 [EthernetAny]
963
964
965 [InterFEid]
966
967
968
970
971 EXCEPTIONOUT
972
973 The exception handling path
974
975
976
977 [EthernetAny]
978
979
980 [ExceptionID]
981 [InterFEid]
982
983
984
986
988
990
991 IFETable
992
993 the table of all InterFE relations
994
995
996 IFEInfo
997
998
999
1000 IFEStats
1001
1002 the stats corresponding to the IFETable table
1004
1005 bstats
1006
1008
1010
1011
1012
1014 Figure 9: Inter-FE LFB XML
1016 7. Acknowledgements
1018 The authors would like to thank Joel Halpern and Dave Hood for the
1019 stimulating discussions. Evangelos Haleplidis contributed to
1020 improving this document.
1022 8. IANA Considerations
1024 This memo includes two IANA requests within the registry
1025 https://www.iana.org/assignments/forces
1027 The first request is for the sub-registry "Logical Functional Block
1028 (LFB) Class Names and Class Identifiers" to request for the
1029 reservation of LFB class name IFE with LFB classid 6112 with version
1030 1.0.
1032 The second request is for the sub-registry "Metadata ID" to request
1033 for the InterFEid metadata the value 0x00000010.
1035 9. IEEE Assignment Considerations
1037 This memo includes a request for a new ethernet protocol type as
1038 described in Section 5.1.
1040 10. Security Considerations
1042 This document does not alter either the ForCES model the ForCES Model
1043 [RFC5812] or the ForCES Protocol [RFC5810] As such, it has no impact
1044 on their security considerations. This document simply defines the
1045 operational parameters and capabilities of an LFB that performs LFB
1046 class instance extensions across nodes under a single administrative
1047 control. this document does not attempt to analyze the presence or
1048 possibility of security interactions created by allowing LFB graph
1049 extension on packets. Any such issues, if they exist, are for the
1050 designers of the particular data path, not the general mechanism.
1052 11. References
1054 11.1. Normative References
1056 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
1057 "Forwarding and Control Element Separation (ForCES)
1058 Framework", RFC 3746, April 2004.
1060 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
1061 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
1062 Control Element Separation (ForCES) Protocol
1063 Specification", RFC 5810, March 2010.
1065 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
1066 Layer (TML) for the Forwarding and Control Element
1067 Separation (ForCES) Protocol", RFC 5811, March 2010.
1069 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
1070 Element Separation (ForCES) Forwarding Element Model",
1071 RFC 5812, March 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, March 1997.
1078 [RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
1079 Halpern, "Forwarding and Control Element Separation
1080 (ForCES) Logical Function Block (LFB) Library", RFC 6956,
1081 June 2013.
1083 [brcm-higig]
1084 "Higig", .
1086 [linux-tc]
1087 Hadi Salim, J., "Linux Traffic Control Classifier-Action
1088 Subsystem Architecture", netdev 01, Feb 2015.
1090 [tc-ife] Hadi Salim, J. and D. Joachimpillai, "Distributing Linux
1091 Traffic Control Classifier-Action Subsystem", netdev 01,
1092 Feb 2015.
1094 [vxlan-udp]
1095 "iproute2 and kernel code (drivers/net/vxlan.c)",
1096 .
1098 Authors' Addresses
1100 Damascane M. Joachimpillai
1101 Verizon
1102 60 Sylvan Rd
1103 Waltham, Mass. 02451
1104 USA
1106 Email: damascene.joachimpillai@verizon.com
1108 Jamal Hadi Salim
1109 Mojatatu Networks
1110 Suite 400, 303 Moodie Dr.
1111 Ottawa, Ontario K2H 9R4
1112 Canada
1114 Email: hadi@mojatatu.com