idnits 2.17.1 draft-joachimpillai-forces-interfelfb-05.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 (December 4, 2014) is 3430 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6956' is mentioned on line 199, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: Informational J. Hadi Salim 5 Expires: June 7, 2015 Mojatatu Networks 6 December 4, 2014 8 ForCES Inter-FE LFB 9 draft-joachimpillai-forces-interfelfb-05 11 Abstract 13 Forwarding and Control Element Separation (ForCES) defines an 14 architectural framework and associated protocols to standardize 15 information exchange between the control plane and the forwarding 16 plane in a ForCES Network Element (ForCES NE). RFC5812 has defined 17 the ForCES Model which provides a formal way to represent the 18 capabilities, state, and configuration of forwarding elements(FEs) 19 within the context of the ForCES protocol. More specifically, the 20 model describes the logical functions that are present in an FE, what 21 capabilities these functions support, and how these functions are or 22 can be interconnected. The control elements (CEs) can control the 23 FEs using the ForCES model definition. 25 The ForCES WG charter has been extended to allow the LFB topology to 26 be across FEs. This documents describes a non-intrusive way to 27 extend the LFB topology across FEs. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 7, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Problem Scope And Use Cases . . . . . . . . . . . . . . . . . 4 68 3.1. Basic Router . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1.1. Distributing The LFB Topology . . . . . . . . . . . . 6 70 3.2. Arbitray Network Function . . . . . . . . . . . . . . . . 7 71 3.2.1. Distributing The Arbitray Network Function . . . . . . 8 72 4. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 9 73 4.1. Inserting The Inter-FE LFB . . . . . . . . . . . . . . . . 9 74 5. Inter-FE connectivity . . . . . . . . . . . . . . . . . . . . 11 75 5.1. Inter-FE Ethernet connectivity . . . . . . . . . . . . . . 13 76 5.1.1. Inter-FE Ethernet Connectivity Issues . . . . . . . . 15 77 6. Detailed Description of the Ethernet inter-FE LFB . . . . . . 15 78 6.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 16 79 6.1.1. Egress Processing . . . . . . . . . . . . . . . . . . 16 80 6.1.2. Ingress Processing . . . . . . . . . . . . . . . . . . 18 81 6.2. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 6.3. Components . . . . . . . . . . . . . . . . . . . . . . . . 19 83 6.4. Inter-FE LFB XML Model . . . . . . . . . . . . . . . . . . 19 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Terminology and Conventions 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 1.2. Definitions 102 This document reiterates the terminology defined in several ForCES 103 documents [RFC3746], [RFC5810], [RFC5811], and [RFC5812] for the sake 104 of contextual clarity. 106 Control Engine (CE) 108 Forwarding Engine (FE) 110 FE Model 112 LFB (Logical Functional Block) Class (or type) 114 LFB Instance 116 LFB Model 118 LFB Metadata 120 ForCES Component 122 LFB Component 124 ForCES Protocol Layer (ForCES PL) 126 ForCES Protocol Transport Mapping Layer (ForCES TML) 128 2. Introduction 130 In the ForCES architecture, a packet service can be modelled by 131 composing a graph of one or more LFB instances. The reader is 132 refered to the details in the ForCES Model [RFC5812]. 134 The FEObject LFB capabilities in the ForCES Model [RFC5812] define 135 component ModifiableLFBTopology which, when advertised with by the 136 FE, implies that the advertising FE is capable of allowing creation 137 and modification the LFB graph by the control plane. Details on how 138 a graph of LFB class instances can be created can be derived by the 139 control plane by looking at the FE's FEObject LFB table 140 SupportedLFBs. That table contains information about each LFB class 141 that the FE supports. For each LFB class supported, details are 142 provided on how that LFB class may be connected to other LFB classes. 143 The SupportedLFBs table describes which LFB class a specified LFB 144 class may succeed or precede in an LFB class instance topology. Each 145 link connecting two LFB class instances is described in the 146 LFBLinkType dataTypeDef and has sufficient details to identify 147 precisely the end points of a link of a service graph. 149 The CE may therefore create a packet service by describing an LFB 150 instance graph connections; achieved by updating the FEOBject 151 LFBTopology table. 153 Often there are requirements for the packet service graph to cross FE 154 boundaries. This could be from a desire to scale the service or need 155 to interact with LFBs which reside in a separate FE (eg lookaside 156 interface to a shared TCAM, an interconnected chip, or as coarse 157 grained functionality as an external NAT FE box being part of the 158 service graph etc). 160 Given that the ForCES inter-LFB architecture calls out for ability to 161 pass metadata between LFBs, it is imperative therefore to define 162 mechanisms to extend that existing feature and allow passing the 163 metadata between LFBs across FEs. 165 The new ForCES charter allows the LFB links in a topology to be 166 across multiple FE (inter-FE connectivity). 168 This document describes extending the LFB topology across FEs i.e 169 inter-FE connectivity without needing any changes to the ForCES 170 definitions. It focusses on using Ethernet as the interconnection as 171 a starting point while leaving room for other protocols (such as 172 directly on top of IP, UDP, VXLAN, etc) for different documents. 174 3. Problem Scope And Use Cases 176 The scope of this document is to solve the challenge of passing 177 ForCES defined metadata and exceptions across FEs (be they physical 178 or virtual). To illustrate the problem scope we present two use 179 cases where we start with a single FE running all the functionality 180 then split it into multiple FEs. 182 3.1. Basic Router 184 A sample LFB topology Figure 1 demonstrates a service graph for 185 delivering basic IPV4 forwarding service within one FE. Note: 187 although the diagram shows LFB classes connecting in the graph in 188 reality it is a graph of LFB class instances that are inter- 189 connected. 191 Since the illustration is meant only as an exercise to showcase how 192 data and metadata is sent down or upstream on a graph of LFBs, it 193 abstracts out any ports in both directions and talks about a generic 194 ingress and egress LFB. Again, for illustration purposes, the 195 diagram does not show expection or error paths. Also left out are 196 details on Reverse Path Filtering, ECMP, multicast handling etc. In 197 other words, this is not meant to be a complete description of an 198 IPV4 forwarding application; for a more complete example, please 199 refer to the LFBlib document [RFC6956] . 201 The output of the ingress LFB(s) coming into the IPv4 Validator LFB 202 will have both the IPV4 packets and, depending on the implementation, 203 a variety of ingress metadata such as offsets into the different 204 headers, any classification metadata, physical and virtual ports 205 encountered, tunnelling information etc. These metadata are lumped 206 together as "ingress metadata". 208 Once the IPV4 validator vets the packet (example ensures that no 209 expired TTL etc), it feeds the packet and inherited metadata into the 210 IPV4 unicast LPM LFB. 212 +----+ 213 | | 214 IPV4 pkt | | IPV4 pkt +-----+ +---+ 215 +------------->| |------------->| | | | 216 | + ingress | | + ingress |IPv4 | IPV4 pkt | | 217 | metadata | | metadata |Ucast|------------>| |--+ 218 | +----+ |LPM | + ingress | | | 219 +-+-+ IPv4 +-----+ + NHinfo +---+ | 220 | | Validator metadata IPv4 | 221 | | LFB NextHop| 222 | | LFB | 223 | | | 224 | | IPV4 pkt 225 | | + {ingress 226 +---+ + NHdetails} 227 Ingress metadata | 228 LFB +-------+ | 229 |Egress | | 230 <--|LFB |<------------------+ 231 +-------+ 233 Figure 1: Basic IPV4 packet service LFB topology 235 The IPV4 unicast LPM LFB does a longest prefix match lookup on the 236 IPV4 FIB using the destination IP address as a search key. The 237 result is typically a next hop selector which is passed downstream as 238 metadata. 240 The Nexthop LFB receives the IPv4 packet with an associated next hop 241 info metadata. The NextHop LFB consumes the NH info metadata and 242 derives from it a table index to look up the next hop table in order 243 to find the appropriate egress information. The lookup result is 244 used to build the next hop details to be used downstream on the 245 egress. This information may include any source and destination 246 information (MAC address to use, if ethernet;) as well egress ports. 247 [Note: It is also at this LFB where typically the forwarding TTL 248 decrement and IP checksum recalculation occurs.] 250 The details of the egress LFB are considered out of scope for this 251 discussion. Suffice it is to say that somewhere within or beyond the 252 Egress LFB the IPV4 packet will be sent out a port (ethernet, virtual 253 or physical etc). 255 3.1.1. Distributing The LFB Topology 257 Figure 2 demonstrates one way the router LFB topology in Figure 1 may 258 be split across two FEs (eg two ASICs). Figure 2 shows the LFB 259 topology split across FEs after the IPV4 unicast LPM LFB. 261 FE1 262 +-------------------------------------------------------------+ 263 | +----+ | 264 | +----------+ | | | 265 | | Ingress | IPV4 pkt | | IPV4 pkt +-----+ | 266 | | LFB |+------------->| |------------->| | | 267 | | | + ingress | | + ingress |IPv4 | | 268 | +----------+ metadata | | metadata |Ucast| | 269 | ^ +----+ |LPM | | 270 | | IPv4 +-----+ | 271 | | Validator | | 272 | LFB | | 273 +---------------------------------------------------|---------+ 274 | 275 IPv4 packet + 276 {ingress + NHinfo} 277 metadata 278 FE2 | 279 +---------------------------------------------------|---------+ 280 | V | 281 | +--------+ +--------+ | 282 | | Egress | IPV4 packet | IPV4 | | 283 | <-----| LFB |<----------------------|NextHop | | 284 | | |{ingress + NHdetails} | LFB | | 285 | +--------+ metadata +--------+ | 286 +-------------------------------------------------------------+ 288 Figure 2: Split IPV4 packet service LFB topology 290 Some proprietary inter-connect (example Broadcom Higig over XAUI 291 (XXX: ref needed)) maybe exist to carry both the IPV4 packet and the 292 related metadata between the IPV4 Unicast LFB and IPV4 NextHop LFB 293 across the two FEs. 295 The purpose of the inter-FE LFB is to define standard mechanisms for 296 interconnecting FEs and for that reason we are not going to touch 297 anymore on proprietary chip-chip interconnects other than state the 298 fact they exist and that it is feasible to have translation to and 299 from proprietary approaches. The focus is going to stick to FE-FE 300 interconnect where the FE could be physical or virtual and the 301 interconnecting technology runs a standard protocol such as ethernet, 302 IP or other protocols on top of IP. 304 3.2. Arbitray Network Function 306 In this section we show an example of an arbitrary network function 307 which is more coarse grained in terms of functionality. Each Network 308 function may constitute more than one LFB. 310 FE1 311 +-------------------------------------------------------------+ 312 | +----+ | 313 | +----------+ | | | 314 | | Network | pkt |NF2 | pkt +-----+ | 315 | | Function |+------------->| |------------->| | | 316 | | 1 | + NF1 | | + NF1/2 |NF3 | | 317 | +----------+ metadata | | metadata | | | 318 | ^ +----+ | | | 319 | | +-----+ | 320 | | | | 321 | | | 322 +---------------------------------------------------|---------+ 323 V 325 Figure 3: A Network Function Service Chain within one FE 327 The setup in Figure 3 is atypical of most packet processing boxes 328 where we have functions like DPI, NAT, Routing, etc connected in such 329 a topology to deliver a packet processing service to flows. 331 3.2.1. Distributing The Arbitray Network Function 333 The setup in Figure 3 can be split out across 3 FEs instead as 334 demonstrated in Figure 4. This could be motivated by scale out 335 reasons or because different vendors provide different functionality 336 which is plugged-in to provide such functionality. The end result is 337 to have the same packet service delivered to the different flows 338 passing through. 340 FE1 FE2 341 +----------+ +----+ FE3 342 | Network | pkt |NF2 | pkt +-----+ 343 | Function |+------------->| |------------->| | 344 | 1 | + NF1 | | + NF1/2 |NF3 | 345 +----------+ metadata | | metadata | | 346 ^ +----+ | | 347 | +-----+ 348 | 349 V 351 Figure 4: A Network Function Service Chain Distributed Across 352 Multiple FEs 354 4. Proposal Overview 356 We address the inter-FE connectivity by proposing an inter-FE LFB. 357 Using an LFB implies no change to the basic ForCES architecture in 358 the form of the core LFBs (FE Protocol or Object LFBs). This design 359 choice was made after considering an alternative approach that would 360 have required changes to both the FE Object capabilities 361 (SupportedLFBs) as well LFBTopology component to describe the 362 inter-FE connectivity capabilities as well as runtime topology of the 363 LFB instances. 365 4.1. Inserting The Inter-FE LFB 367 The distributed LFB topology described in Figure 2 is re-illustrated 368 in Figure 5 to show the topology location where the inter-FE LFB 369 would fit in. 371 FE1 372 +-------------------------------------------------------------+ 373 | +----------+ +----+ | 374 | | Ingress | IPV4 pkt | | IPV4 pkt +-----+ | 375 | | LFB |+------------->| |------------->| | | 376 | | | + ingress | | + ingress |IPv4 | | 377 | +----------+ metadata | | metadata |Ucast| | 378 | ^ +----+ |LPM | | 379 | | IPv4 +-----+ | 380 | | Validator | | 381 | | LFB | | 382 | | IPv4 pkt + metadata | 383 | | {ingress + NHinfo + InterFEid}| 384 | | | | 385 | +----V----+ | 386 | | InterFE | | 387 | | LFB | | 388 | +---------+ | 389 +---------------------------------------------------|---------+ 390 | 391 IPv4 packet and metadata 392 {ingress + NHinfo + Inter FE info} 393 FE2 | 394 +---------------------------------------------------|---------+ 395 | +----V----+ | 396 | | InterFE | | 397 | | LFB | | 398 | +---------+ | 399 | | | 400 | IPv4 pkt + metadata | 401 | {ingress + NHinfo} | 402 | | | 403 | +--------+ +----V---+ | 404 | | Egress | IPV4 packet | IPV4 | | 405 | <-----| LFB |<----------------------|NextHop | | 406 | | |{ingress + NHdetails} | LFB | | 407 | +--------+ metadata +--------+ | 408 +-------------------------------------------------------------+ 410 Figure 5: Split IPV4 forwarding service with Inter-FE LFB 412 As can be observed in Figure 5, the same details passed between IPV4 413 unicast LPM LFB and the IPV4 NH LFB are passed to the egress side of 414 the Inter-FE LFB. In addition an index for the inter-FE LFB 415 (interFEid) is passed as metadata. 417 The egress of the inter-FE LFB uses the received Inter-FE index 418 (InterFEid metadata) to select details for encapsulation towards the 419 neighboring FE. These details will include what the source and 420 destination FEID to be communicated to the neighboring FE. In 421 addition the original metadata, any exception IDs may be passed along 422 with the original IPV4 packet. 424 On the ingress side of the inter-FE LFB the received packet and its 425 associated details are used to decide the graph continuation i.e 426 which FE instance is to be passed the packet and what of the original 427 metadata and exception IDs. In the illustrated case above, an IPV4 428 Nexthop LFB instance metadata is passed. 430 The ingress side of the inter-FE LFB consumes some of the information 431 passed (eg the destination FEID) and passes on the IPV4 packet 432 alongside with the ingress + NHinfo metadata to the IPV4 NextHop LFB 433 as was done earlier in both Figure 1 and Figure 2. 435 5. Inter-FE connectivity 437 We describe the generic encapsulation format in Figure 6 extended 438 from the ForCES redirect packet format. We intend for this 439 encapsulation to be a generic guideline of the different needed 440 fields to be made available by any used transport for inter-FE LFB 441 connectivity. We expect that for any transport mechanism used, that 442 a description of how the different fields will be encapsulated to be 443 correlated to the information described in Figure 6. The goal of 444 this document is to provide ethernet encapsulation, and to that end 445 in Section 5.1 we illustrate how we use the guidelines provided in 446 this section to describe the fit for inter-FE LFB interfacing over 447 ethernet. 449 +-- Main ForCES header 450 | | 451 | +---- msg type = REDIRECT 452 | +---- Destination FEID 453 | +---- Source FEID 454 | +---- NEID (first word of Correlator) 455 | 456 +-- T = ExceptionID-TLV 457 | | 458 | +-- +-Exception Data ILV (I = exceptionID , L= length) 459 | | | | 460 | | | +----- V= Metadata value 461 | . | 462 | . | 463 | . +-Exception Data ILV 464 . 465 | 466 +- T = METADATA-TLV 467 | | 468 | +-- +-Meta Data ILV (I = metaid, L= length) 469 | | | | 470 | | | +----- V= Metadata value 471 | . | 472 | . | 473 | . +-Meta Data ILV 474 . 475 +- T = REDIRECTDATA-TLV 476 | 477 +-- Redirected packet Data 479 Figure 6: Packet format suggestion 481 o The ForCES main header as described in RFC5810 is used as a fixed 482 header to describe the Inter-FE encapsulation. 484 * The Source ID field is mapped to the originating FE and the 485 destination ID is mapped to the destination FEID. 487 * The first 32 bits of the correlator field are used to carry the 488 NEID. The 32-bit NEID defaults to 0. 490 o The ExceptionID TLV carries one or more exception IDs within ILVs. 491 The I in the ILV carries a globally defined exceptionID as per- 492 ForCES specification defined by IANA. This TLV is new to ForCES 493 and sits in the global ForCES TLV namespace. 495 o The METADATA and REDIRECTDATA TLV encapsulations are taken 496 directly from [RFC5810] section 7.9. 498 It is expected that a variety of transport encapsulations would be 499 applicable to carry the format described in Figure 6. In such a 500 case, a description of a mapping to intepret the inter-FE details and 501 translate into proprietary or legacy formatting would need to be 502 defined. For any mapping towards these definitions a different 503 document to describe the mapping, one per transport, is expected to 504 be defined. 506 5.1. Inter-FE Ethernet connectivity 508 In this specific document, we describe a format that is to be used 509 over Ethernet. 511 The following describes the mapping from Figure 6 to ethernet wire 512 encapsulation illustrated in Figure 7. 514 o When an NE tag is needed, a VLAN tag will be used. Note: that the 515 NEID as per Figure 6 is described as being 32 bits while a vlan 516 tag is 12 bits. It is however thought to be sufficient to use 12 517 bits within the scope of a LAN NE cluster. 519 o An ethernet type will be used to imply that a wire format is 520 carrying an inter-FE LFB packet. The ethernet type will be 521 requested from the appropriate IEEE Standards Association. We 522 feel that given that a ForCES NE may end up being owned by a 523 single organization, the CE could program all participating FEs 524 via the inter-FE LFB (described in this document) to recognize a 525 private ethernet type used for inter-LFB traffic. 527 o The destination FEID will be mapped to the destination MAC address 528 of the target FEID. 530 o The source FEID will be mapped to the source MAC address of the 531 originating FEID. 533 o In this version of the specification, we only focus on data and 534 metadata. Therefore we are not going to describe how to carry the 535 ExceptionID information (future versions may). We are also not 536 going to use METADATA-TLV or REDIRECTDATA-TLV in order to save 537 shave off some overhead bytes. Figure 7 describes the payload 538 when 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Outer Destination MAC Address (Destination FEID) | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Outer Destination MAC Address | Outer Source MAC Address | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Outer Source MAC Address (Source FEID) | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Optional 802.1Q info (NEID) | Inter-FE ethertype | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Metadata length | TLV encoded Metadata | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | TLV encoded Metadata ~~~..............~~ | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Original Ethernet payload ~~................~~ | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Figure 7: Packet format suggestion 559 An outer Ethernet header is introduced to carry the information on 560 Destination FEID, Source FEID and optional NEID. 562 o The Outer Destination MAC Address carries the Destination FEID 563 identification. 565 o Outer Source MAC Address carries the Source FEID identification. 567 o When an NEID is needed, an optional 802.1Q is carried with 12-bit 568 VLANid representing the NEID. 570 o The ethernet type is used to identify the frame as inter-FE LFB 571 type. 573 o The 16-bit metadata length is used to described the total encoded 574 metadata length (including the 16 bits used to encode the metadata 575 length). 577 o One or more TLV encoded metadatum follows the metadata length 578 field. The TLV type identifies the Metadata id. We recognize 579 that this restricts the metadata id to 16 bits instead of ForCES 580 define space of 32 bits. However, at the time of publication we 581 believe this is sufficient to carry all the info we need and this 582 would save us 4 bytes per Metadata transferred. XXX: If there is 583 objection from the we could convert this to an ILV. 585 o The original ethernet payload is appended at the end. 587 5.1.1. Inter-FE Ethernet Connectivity Issues 589 There are several issues that may arise due to using direct ethernet 590 encapsulation. 592 o Because we are adding data to existing ethernet frames, MTU issues 593 may arise. We recommend: 595 * To use large MTUs when possible (example with jumbo frames). 597 * Limit the amount of metadata that could be transmitted; our 598 definition allows for filtering of which metadata is to be 599 encapsulated in the frame. We recommend complementing this by 600 setting the egress port MTU to allow space for maximum size of 601 the metadata total size you wish to allow between FEs. MTU 602 setting can be achieved by configuration or ForCES control of 603 the port LFB. An extra 64 bytes reserved on the MTU will 604 account for 5 32-bit metadatum or 3 64-bit metadatum. In 605 essence, the control plane making a decision for the MTU size 606 of the egress port is implicitly deciding how much metadata 607 will be allowed. 609 o The frame may be dropped if there is congestion on the receiving 610 FE side. One approach to mitigate this issue is to make sure that 611 inter-FE LFB frames receive the highest priority treatment when 612 scheduled on the wire. Typically protocols that tunnel in the 613 middle box do not care and depend on the packet originator to 614 resend if the originator cares about reliability. We do not 615 expect to be any different. 617 6. Detailed Description of the Ethernet inter-FE LFB 619 The ethernet inter-FE LFB has two LFB input ports and three LFB 620 output ports. 622 +-----------------+ 623 Inter-FE LFB | | 624 Encapsulated | OUT2+--> decapsulated Packet + metadata 625 -------------->|IN2 | 626 Packet | | 627 | | 628 raw Packet + | OUT1+--> encapsulated Packet 629 -------------->|IN1 | 630 Metadata | | 631 | EXCEPTIONOUT +--> Errorid, packet + metadata 632 | | 633 +-----------------+ 635 Figure 8: Inter-FE LFB 637 6.1. Data Handling 639 The Inter-FE LFB will be positioned at the egress of an FE at the 640 source FE. In such a case an Inter-FE LFB instance receives via port 641 IN1, raw packet and metadata IDs from the preceeding LFB instance. 642 The InterFEid metadatum MAY be present on the incoming raw data. The 643 processed encapsulated packet will go out on either LFB port OUT1 to 644 a downstream LFB or EXCEPTIONOUT port in the case of a failure. 646 The Inter-FE LFB will be positioned at the ingress of a receiving FE. 647 In such a case an Inter-FE LFB receives, via port IN2, an 648 encapsulated packet. Successful processing of the packet will result 649 in a raw packet with associated metadata IDs going downstream to an 650 LFB connected on OUT2. On failure the data is sent out EXCEPTIONOUT. 652 Depending on the implementation, the Inter-FE LFB may use the 653 InterFEid metadatum on egress of an FE to lookup the NextFE table. 654 The interFEid in such a case will be generated by an upstream LFB 655 instance (i.e one preceeding the Inter-FE LFB). The output result 656 constitutes a matched table row which has the InterFEinfo details 657 i.e. the tuple {NEID,Destination FEID,Source FEID, inter FE type, 658 metafilters}. The metafilters lists define which Metadatum are to be 659 passed to the neighboring FE. XXX: alternative implementations may 660 preprogram the Inter-FE LFB details to be used (and therefore do not 661 need presence of InterFEid metadatum). We look at the InterFEid 662 metadatum as lowest common denominator for inter-operability but 663 leave it up to the implementation to make the call. 665 6.1.1. Egress Processing 667 The egress Inter-FE LFB will receive an ethernet frame and 668 accompanying metadatum (including optionally the InterFEid 669 metadatum). The ethernet frame may be 802.1Q tagged. 671 The InterFEid may be used to lookup NextFE table. If lookup is 672 successful, the inter-FE LFB will perform the following actions: 674 o create the outer ethernet header which is a duplicate of the 675 incoming frame's ethernet header. The outer ethernet header may 676 have an optional 802.1q header. 678 o If the NEID field is present (not 0) and the original header had a 679 vlan tag, replace the vlan tag on the outer header with the value 680 from the matched NEID field. If the NEID field is present (not 0) 681 and the original header did not have a vlan tag, create one that 682 matches the NEID field and appropriately add it to the outer 683 header. If the NEID field is absent or 0, do nothing. 685 o Set the Destination MAC address of the outer header with value 686 found in the DSTFE field. 688 o If the optional SRCFE is present, set the Source MAC address of 689 the outer header with value found in the SRCFE field. If SRCFE is 690 absent then the inner source MAC address is used (at this point 691 already copied). 693 o If the optional IFETYPE is present, set the outer ethernet type to 694 the value found in IFETYPE. If IFETYPE is absent then the 695 standard ethernet type is used (XXX: to be requested from IEEE). 697 o Walk the passed metadatum, apply against the MetaFilterList and 698 encapsulate each allowed metadatum in a TLV. Use the Metaid as 699 the "type" field in the TLV header. The TLV should be aligned to 700 32 bits. This means you may need to add padding of zeroes to 701 ensure alignment. 703 o Update the Metadata length to the sum of each TLV's space + 2 704 bytes (for the Metadata length field 16 bit space). 706 The resulting packet is sent to the LFB instance connected to the 707 OUT1; typicall a port LFB. 709 In the case of a failed lookup or a zero-value InterFEid, or absence 710 of InterFEid, the default inter-FE LFB processing will: 712 o create the outer ethernet header which is a duplicate of the 713 incoming frame's ethernet header. The outer ethernet header may 714 have an optional 802.1q header. 716 o If the DefaultNextFE NEID component is not 0 and the original 717 header had a vlan tag, replace the vlan tag on the outer header 718 with the value from the matched DefaultNextFE NEID field. If the 719 DefaultNextFE NEID field is present (not 0) and the original 720 header did not have a vlan tag, create one that matches the 721 DefaultNextFE NEID field and appropriately add it to the outer 722 header. If the DefaultNextFE NEID field is absent or 0, do 723 nothing. 725 o Set the Destination MAC address of the outer header with value 726 found in the DefaultNextFE DSTFE component. 728 o If the DefaultNextFE SRCFE is non-zero, set the Source MAC address 729 of the outer header with value found in the DefaultNextFE SRCFE 730 field. If DefaultNextFE SRCFE is zero then the inner source MAC 731 address is used (at this point already copied). 733 o If the optional DefaultNextFE IFETYPE is non-zero, set the outer 734 ethernet type to the value found in DefaultNextFE IFETYPE. If 735 DefaultNextFE IFETYPE is zero then the standard ethernet type is 736 used (XXX: to be requested from IEEE). 738 o Walk all the passed metadatum, apply against the DefaultNextFE 739 MetaFilterList and encapsulate each allowed metadatum in a TLV. 740 Use the Metaid as the "type" field in the TLV header. The TLV 741 should be aligned to 32 bits. This means you may need to add 742 padding of zeroes to ensure alignment. 744 o Update the Metadata length to the sum of each TLV's space + 2 745 bytes (for the Metadata length field 16 bit space). 747 The resulting packet is sent to the LFB instance connected to the 748 OUT1 LFB port (typicall a Port LFB). 750 6.1.2. Ingress Processing 752 An inter-FE LFB packet is recognized by looking at the etherype. 754 o The inter-FE LFB instance looks at the metadata length field and 755 walks the packet data extracting from the TLVs the metadata 756 values. For each metadata extracted, the corresponding 757 implementation metadatum field is set. 759 o Upon completion of processing all the metadata, the inter-FE LFB 760 instance resets the header to point to the original (inner) 761 ethernet header i.e skips the metadata information. At this point 762 the the original ethernet frame that was passed to the egress 763 Inter-FE LFB at the source FE is reconstructed. This data is then 764 passed alongside the reconstructed metadata downstream to the next 765 programmed LFB instance. 767 In the case of processing failure of either ingress or egress 768 positioning of the LFB, the packet and metadata are sent out the 769 EXCEPTIONOUT LFB port with proper error id (XXX: More description to 770 be added). 772 6.2. Metadata 774 A single (to be define from IANA space) metadatum, InterFEid, is 775 defined. 777 6.3. Components 779 There are two LFB component populated by the CE. Each components 780 information is of type IFEInfo. The IFEInfo datatype constitutes: 781 NEID, optional IFETYPE, Destination FEID(DSTFE), optional Source FEID 782 (SRCFE), array of allowed Metaids (MetaFilterList). 784 The CE optionally programs LFB instances in a service graph that 785 require inter-FE connectivity with InterFEid values to correspond to 786 the inter-FE LFB NextFE table entries to use. 788 The first component is an array known as the NextFE table. The array 789 rows are made up of IFEInfo structure. The table is looked up by a 790 32 bit index passed from an upstream LFB class instance in the form 791 of InterFEid metadatum. 793 The second component(ID 2) is an IFEInfo structure known as 794 DefaultNextFE. The DefaultNextFE component carries similar 795 information to any one table row in the NextFE table and is used as 796 the default source of Inter-FE encapsulation information if there is 797 failure to use any entry in the NextFE table. 799 6.4. Inter-FE LFB XML Model 801 XXX: add ports and metadata definition 803 XXX: add stats as in implementation (including error stats) 805 808 810 811 IFEInfo 812 Describing IFE table row Information 813 814 815 NEID 816 817 The VLAN Id 12 bits part of the 802.1q TCI field. 818 819 uint16 820 821 822 IFETYPE 823 824 the ethernet type to be used for outgoing IFE frame 825 826 827 uint16 828 829 830 DSTFE 831 832 the destination MAC address of destination FE 833 834 byte[6] 835 836 837 SRCFE 838 839 the source MAC address used for the source FE 840 841 842 byte[6] 843 844 845 MetaFilterList 846 847 the metadata filter table 848 849 850 uint32 851 852 853 854 856 858 859 860 IFE 861 862 This LFB describes IFE connectivity parametrization 863 864 1.0 866 868 869 NextFE 870 871 the table of all InterFE relations 872 873 874 IFEInfo 875 876 878 879 DefaultNextFE 880 881 the Default Next FE info. Used when we are not able 882 to determine what to use from NextFE 883 884 IFEInfo 885 887 889 890 891 893 Figure 9: Inter-FE LFB XML 895 7. Acknowledgements 897 The authors would like to thank Joel Halpern and Dave Hood for the 898 stimulating discussions. 900 8. IANA Considerations 902 This memo includes two IANA requests within the registry 903 https://www.iana.org/assignments/forces 904 The first request is for the sub-registry "Logical Functional Block 905 (LFB) Class Names and Class Identifiers" to request for the 906 reservation of LFB class name IFE with LFB classid 6112 with version 907 1.0. 909 The second request is for the sub-registry "Metadata ID" to request 910 for the InterFEid metadata the value 0x00000010. 912 9. Security Considerations 914 TBD 916 10. References 918 10.1. Normative References 920 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 921 "Forwarding and Control Element Separation (ForCES) 922 Framework", RFC 3746, April 2004. 924 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 925 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 926 Control Element Separation (ForCES) Protocol 927 Specification", RFC 5810, March 2010. 929 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 930 Layer (TML) for the Forwarding and Control Element 931 Separation (ForCES) Protocol", RFC 5811, March 2010. 933 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 934 Element Separation (ForCES) Forwarding Element Model", 935 RFC 5812, March 2010. 937 10.2. Informative References 939 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 940 Requirement Levels", BCP 14, RFC 2119, March 1997. 942 Authors' Addresses 944 Damascane M. Joachimpillai 945 Verizon 946 60 Sylvan Rd 947 Waltham, Mass. 02451 948 USA 950 Email: damascene.joachimpillai@verizon.com 952 Jamal Hadi Salim 953 Mojatatu Networks 954 Suite 400, 303 Moodie Dr. 955 Ottawa, Ontario K2H 9R4 956 Canada 958 Email: hadi@mojatatu.com