idnits 2.17.1 draft-ietf-forces-interfelfb-00.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 (January 4, 2015) is 3399 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: 'RFC6956' is mentioned on line 186, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3746 Summary: 1 error (**), 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: Standards Track J. Hadi Salim 5 Expires: July 8, 2015 Mojatatu Networks 6 January 4, 2015 8 ForCES Inter-FE LFB 9 draft-ietf-forces-interfelfb-00 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 definitions by defining the Inter-FE LFB. The Inter-FE LFB provides 16 ability to pass data, metadata and exceptions across FEs. The 17 document describes a generic way to transport the mentioned details 18 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 July 8, 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. Security Considerations . . . . . . . . . . . . . . . . . . . 24 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 82 1. Terminology and Conventions 84 1.1. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 1.2. Definitions 92 This document reiterates the terminology defined in several ForCES 93 documents [RFC3746], [RFC5810], [RFC5811], and [RFC5812] for the sake 94 of contextual clarity. 96 Control Engine (CE) 98 Forwarding Engine (FE) 100 FE Model 102 LFB (Logical Functional Block) Class (or type) 104 LFB Instance 106 LFB Model 108 LFB Metadata 110 ForCES Component 112 LFB Component 114 ForCES Protocol Layer (ForCES PL) 116 ForCES Protocol Transport Mapping Layer (ForCES TML) 118 2. Introduction 120 In the ForCES architecture, a packet service can be modelled by 121 composing a graph of one or more LFB instances. The reader is 122 referred to the details in the ForCES Model [RFC5812]. 124 The FEObject LFB capabilities in the ForCES Model [RFC5812] define 125 component ModifiableLFBTopology which, when advertised by the FE, 126 implies that the advertising FE is capable of allowing creation and 127 modification the LFB graph by the control plane. Details on how a 128 graph of LFB class instances can be created can be derived by the 129 control plane by looking at the FE's FEObject LFB class table 130 component SupportedLFBs. The SupportedLFBs table contains 131 information about each LFB class that the FE supports. For each LFB 132 class supported, details are provided on how the supported LFB class 133 may be connected to other LFB classes. The SupportedLFBs table 134 describes which LFB class a specified LFB class may succeed or 135 precede in an LFB class instance topology. Each link connecting two 136 LFB class instances is described in the LFBLinkType dataTypeDef and 137 has sufficient details to identify precisely the end points of a link 138 of a service graph. 140 The CE may therefore create a packet service by describing an LFB 141 instance graph connection; this is achieved by updating the FEOBject 142 LFBTopology table. 144 Often there are requirements for the packet service graph to cross FE 145 boundaries. This could be from a desire to scale the service or need 146 to interact with LFBs which reside in a separate FE (eg lookaside 147 interface to a shared TCAM, an interconnected chip, or as coarse 148 grained functionality as an external NAT FE box being part of the 149 service graph etc). 151 Given that the ForCES inter-LFB architecture calls out for ability to 152 pass metadata between LFBs, it is imperative therefore to define 153 mechanisms to extend that existing feature and allow passing the 154 metadata between LFBs across FEs. 156 This document describes extending the LFB topology across FEs i.e 157 inter-FE connectivity without needing any changes to the ForCES 158 definitions. It focusses on using Ethernet as the interconnection as 159 a starting point while leaving room for other protocols (such as 160 directly on top of IP, UDP, VXLAN, etc) to be addressed by other 161 future documents. 163 3. Problem Scope And Use Cases 165 The scope of this document is to solve the challenge of passing 166 ForCES defined metadata and exceptions across FEs (be they physical 167 or virtual). To illustrate the problem scope we present two use 168 cases where we start with a single FE running all the functionality 169 then split it into multiple FEs. 171 3.1. Basic Router 173 A sample LFB topology Figure 1 demonstrates a service graph for 174 delivering basic IPV4 forwarding service within one FE. For the 175 purpose of illustration, the diagram shows LFB classes as graph nodes 176 instead of multiple LFB class instances. 178 Since the illustration is meant only as an exercise to showcase how 179 data and metadata are sent down or upstream on a graph of LFBs, it 180 abstracts out any ports in both directions and talks about a generic 181 ingress and egress LFB. Again, for illustration purposes, the 182 diagram does not show exception or error paths. Also left out are 183 details on Reverse Path Filtering, ECMP, multicast handling etc. In 184 other words, this is not meant to be a complete description of an 185 IPV4 forwarding application; for a more complete example, please 186 refer to the LFBlib document [RFC6956] . 188 The output of the ingress LFB(s) coming into the IPv4 Validator LFB 189 will have both the IPV4 packets and, depending on the implementation, 190 a variety of ingress metadata such as offsets into the different 191 headers, any classification metadata, physical and virtual ports 192 encountered, tunnelling information etc. These metadata are lumped 193 together as "ingress metadata". 195 Once the IPV4 validator vets the packet (example ensures that no 196 expired TTL etc), it feeds the packet and inherited metadata into the 197 IPV4 unicast LPM LFB. 199 +----+ 200 | | 201 IPV4 pkt | | IPV4 pkt +-----+ +---+ 202 +------------->| +------------->| | | | 203 | + ingress | | + ingress |IPv4 | IPV4 pkt | | 204 | metadata | | metadata |Ucast+------------>| +--+ 205 | +----+ |LPM | + ingress | | | 206 +-+-+ IPv4 +-----+ + NHinfo +---+ | 207 | | Validator metadata IPv4 | 208 | | LFB NextHop| 209 | | LFB | 210 | | | 211 | | IPV4 pkt | 212 | | + {ingress | 213 +---+ + NHdetails} 214 Ingress metadata | 215 LFB +--------+ | 216 | Egress | | 217 <--+ |<-----------------+ 218 | LFB | 219 +--------+ 221 Figure 1: Basic IPV4 packet service LFB topology 223 The IPV4 unicast LPM LFB does a longest prefix match lookup on the 224 IPV4 FIB using the destination IP address as a search key. The 225 result is typically a next hop selector which is passed downstream as 226 metadata. 228 The Nexthop LFB receives the IPv4 packet with an associated next hop 229 info metadata. The NextHop LFB consumes the NH info metadata and 230 derives from it a table index to look up the next hop table in order 231 to find the appropriate egress information. The lookup result is 232 used to build the next hop details to be used downstream on the 233 egress. This information may include any source and destination 234 information (MAC address to use, if ethernet;) as well egress ports. 235 [Note: It is also at this LFB where typically the forwarding TTL 236 decrement and IP checksum recalculation occurs.] 238 The details of the egress LFB are considered out of scope for this 239 discussion. Suffice it is to say that somewhere within or beyond the 240 Egress LFB the IPV4 packet will be sent out a port (ethernet, virtual 241 or physical etc). 243 3.1.1. Distributing The LFB Topology 245 Figure 2 demonstrates one way the router LFB topology in Figure 1 may 246 be split across two FEs (eg two ASICs). Figure 2 shows the LFB 247 topology split across FEs after the IPV4 unicast LPM LFB. 249 FE1 250 +-------------------------------------------------------------+ 251 | +----+ | 252 | +----------+ | | | 253 | | Ingress | IPV4 pkt | | IPV4 pkt +-----+ | 254 | | LFB +-------------->| +------------->| | | 255 | | | + ingress | | + ingress |IPv4 | | 256 | +----------+ metadata | | metadata |Ucast| | 257 | ^ +----+ |LPM | | 258 | | IPv4 +--+--+ | 259 | | Validator | | 260 | LFB | | 261 +---------------------------------------------------|---------+ 262 | 263 IPv4 packet + 264 {ingress + NHinfo} 265 metadata 266 FE2 | 267 +---------------------------------------------------|---------+ 268 | V | 269 | +--------+ +--------+ | 270 | | Egress | IPV4 packet | IPV4 | | 271 | <-----+ LFB |<----------------------+NextHop | | 272 | | |{ingress + NHdetails} | LFB | | 273 | +--------+ metadata +--------+ | 274 +-------------------------------------------------------------+ 276 Figure 2: Split IPV4 packet service LFB topology 278 Some proprietary inter-connect (example Broadcom Higig over XAUI 279 (XXX: ref needed)) maybe exist to carry both the IPV4 packet and the 280 related metadata between the IPV4 Unicast LFB and IPV4 NextHop LFB 281 across the two FEs. 283 The purpose of the inter-FE LFB is to define standard mechanisms for 284 interconnecting FEs and for that reason we are not going to touch 285 anymore on proprietary chip-chip interconnects other than state the 286 fact they exist and that it is feasible to have translation to and 287 from proprietary approaches. The document focus is the FE-FE 288 interconnect where the FE could be physical or virtual and the 289 interconnecting technology runs a standard protocol such as ethernet, 290 IP or other protocols on top of IP. 292 3.2. Arbitrary Network Function 294 In this section we show an example of an arbitrary network function 295 which is more coarse grained in terms of functionality. Each Network 296 function may constitute more than one LFB. 298 FE1 299 +-------------------------------------------------------------+ 300 | +----+ | 301 | +----------+ | | | 302 | | Network | pkt |NF2 | pkt +-----+ | 303 | | Function +-------------->| +------------->| | | 304 | | 1 | + NF1 | | + NF1/2 |NF3 | | 305 | +----------+ metadata | | metadata | | | 306 | ^ +----+ | | | 307 | | +--+--+ | 308 | | | | 309 | | | 310 +---------------------------------------------------|---------+ 311 V 313 Figure 3: A Network Function Service Chain within one FE 315 The setup in Figure 3 is atypical of most packet processing boxes 316 where we have functions like DPI, NAT, Routing, etc connected in such 317 a topology to deliver a packet processing service to flows. 319 3.2.1. Distributing The Arbitrary Network Function 321 The setup in Figure 3 can be split out across 3 FEs instead as 322 demonstrated in Figure 4. This could be motivated by scale out 323 reasons or because different vendors provide different functionality 324 which is plugged-in to provide such functionality. The end result is 325 to have the same packet service delivered to the different flows 326 passing through. 328 FE1 FE2 329 +----------+ +----+ FE3 330 | Network | pkt |NF2 | pkt +-----+ 331 | Function +-------------->| +------------->| | 332 | 1 | + NF1 | | + NF1/2 |NF3 | 333 +----------+ metadata | | metadata | | 334 ^ +----+ | | 335 | +--+--+ 336 | 337 V 339 Figure 4: A Network Function Service Chain Distributed Across 340 Multiple FEs 342 4. Proposal Overview 344 We address the inter-FE connectivity requirements by proposing the 345 inter-FE LFB class. Using a standard LFB class definition implies no 346 change to the basic ForCES architecture in the form of the core LFBs 347 (FE Protocol or Object LFBs). This design choice was made after 348 considering an alternative approach that would have required changes 349 to both the FE Object capabilities (SupportedLFBs) as well 350 LFBTopology component to describe the inter-FE connectivity 351 capabilities as well as runtime topology of the LFB instances. 353 4.1. Inserting The Inter-FE LFB 355 The distributed LFB topology described in Figure 2 is re-illustrated 356 in Figure 5 to show the topology location where the inter-FE LFB 357 would fit in. 359 FE1 360 +-------------------------------------------------------------+ 361 | +----------+ +----+ | 362 | | Ingress | IPV4 pkt | | IPV4 pkt +-----+ | 363 | | LFB +-------------->| +------------->| | | 364 | | | + ingress | | + ingress |IPv4 | | 365 | +----------+ metadata | | metadata |Ucast| | 366 | ^ +----+ |LPM | | 367 | | IPv4 +--+--+ | 368 | | Validator | | 369 | | LFB | | 370 | | IPv4 pkt + metadata | 371 | | {ingress + NHinfo + InterFEid}| 372 | | | | 373 | +----V----+ | 374 | | InterFE | | 375 | | LFB | | 376 | +----+----+ | 377 +---------------------------------------------------|---------+ 378 | 379 IPv4 packet and metadata 380 {ingress + NHinfo + Inter FE info} 381 FE2 | 382 +---------------------------------------------------|---------+ 383 | +----V----+ | 384 | | InterFE | | 385 | | LFB | | 386 | +----+----+ | 387 | | | 388 | IPv4 pkt + metadata | 389 | {ingress + NHinfo} | 390 | | | 391 | +--------+ +----V---+ | 392 | | Egress | IPV4 packet | IPV4 | | 393 | <-----+ LFB |<----------------------+NextHop | | 394 | | |{ingress + NHdetails} | LFB | | 395 | +--------+ metadata +--------+ | 396 +-------------------------------------------------------------+ 398 Figure 5: Split IPV4 forwarding service with Inter-FE LFB 400 As can be observed in Figure 5, the same details passed between IPV4 401 unicast LPM LFB and the IPV4 NH LFB are passed to the egress side of 402 the Inter-FE LFB. In addition an index for the inter-FE LFB 403 (interFEid) is passed as metadata. 405 The egress of the inter-FE LFB uses the received Inter-FE index 406 (InterFEid metadata) to select details for encapsulation when sending 407 messages towards the selected neighboring FE. These details will 408 include what to communicate as the source and destination FEID; in 409 addition the original metadata and any exception IDs may be passed 410 along with the original IPV4 packet. 412 On the ingress side of the inter-FE LFB the received packet and its 413 associated details are used to decide the packet graph continuation. 414 This includes what of the of the original metadata and exception IDs 415 to restore and what next LFB class instance to continue processing 416 on. In the illustrated case above, an IPV4 Nexthop LFB is selected 417 and metadata is passed on to it. 419 The ingress side of the inter-FE LFB consumes some of the information 420 passed (eg the destination FEID) and passes on the IPV4 packet 421 alongside with the ingress + NHinfo metadata to the IPV4 NextHop LFB 422 as was done earlier in both Figure 1 and Figure 2. 424 5. Generic Inter-FE connectivity 426 In this section we describe the generic encapsulation format in 427 Figure 6 as extended from the ForCES redirect packet format. We 428 intend for the described encapsulation to be a generic guideline of 429 the different needed fields to be made available by any used 430 transport for inter-FE LFB connectivity. We expect that for any 431 transport mechanism used, a description of how the different fields 432 will be encapsulated to be correlated to the information described in 433 Figure 6. The goal of this document is to provide ethernet 434 encapsulation, and to that end in Section 5.1 we illustrate how we 435 use the guidelines provided in this section to describe the fit for 436 inter-FE LFB interfacing over ethernet. 438 +-- Main ForCES header 439 | | 440 | +---- msg type = REDIRECT 441 | +---- Destination FEID 442 | +---- Source FEID 443 | +---- NEID (first word of Correlator) 444 | 445 +-- T = ExceptionID-TLV 446 | | 447 | +-- +-Exception Data ILV (I = exceptionID , L= length) 448 | | | | 449 | | | +----- V= Metadata value 450 | . | 451 | . | 452 | . +-Exception Data ILV 453 . 454 | 455 +- T = METADATA-TLV 456 | | 457 | +-- +-Meta Data ILV (I = metaid, L= length) 458 | | | | 459 | | | +----- V= Metadata value 460 | . | 461 | . | 462 | . +-Meta Data ILV 463 . 464 +- T = REDIRECTDATA-TLV 465 | 466 +-- Redirected packet Data 468 Figure 6: Packet format suggestion 470 o The ForCES main header as described in RFC5810 is used as a fixed 471 header to describe the Inter-FE encapsulation. 473 * The Source FEID field is mapped to the originating FE and the 474 destination FEID is mapped to the destination FEID. 476 * The first 32 bits of the correlator field are used to carry the 477 NEID. The 32-bit NEID defaults to 0. 479 o The ExceptionID TLV carries one or more exception IDs within ILVs. 480 The I in the ILV carries a globally defined exceptionID as per- 481 ForCES specification defined by IANA. This TLV is new to ForCES 482 and sits in the global ForCES TLV namespace. 484 o The METADATA and REDIRECTDATA TLV encapsulations are taken 485 directly from [RFC5810] section 7.9. 487 It is expected that a variety of transport encapsulations would be 488 applicable to carry the format described in Figure 6. In such a 489 case, a description of a mapping to intepret the inter-FE details and 490 translate into proprietary or legacy formatting would need to be 491 defined. For any mapping towards these definitions a different 492 document to describe the mapping, one per transport, is expected to 493 be defined. 495 5.1. Inter-FE Ethernet connectivity 497 In this document, we describe a format that is to be used over 498 Ethernet. 500 The following describes the mapping from Figure 6 to ethernet wire 501 encapsulation illustrated in Figure 7. 503 o When an NE tag is needed, a VLAN tag will be used. Note: that the 504 NEID as per Figure 6 is described as being 32 bits while a vlan 505 tag is 12 bits. It is however thought to be sufficient to use 12 506 bits within the scope of a LAN NE cluster. 508 o An ethernet type will be used to imply that a wire format is 509 carrying an inter-FE LFB packet. The ethernet type will be 510 requested from the appropriate IEEE Standards Association 511 (preferred value is 0xFEFE because it maps nicely to the term 512 FE-FE to imply inter-FE connectivity). 514 o The destination FEID will be mapped to the destination MAC address 515 of the target FEID. 517 o The source FEID will be mapped to the source MAC address of the 518 originating FEID. 520 o In this version of the specification, we only focus on data and 521 metadata. Therefore we are not going to describe how to carry the 522 ExceptionID information (future versions may). We are also not 523 going to use METADATA-TLV or REDIRECTDATA-TLV in order to save 524 shave off some overhead bytes. Figure 7 describes the payload. 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Outer Destination MAC Address (Destination FEID) | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Outer Destination MAC Address | Outer Source MAC Address | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Outer Source MAC Address (Source FEID) | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Optional 802.1Q info (NEID) | Inter-FE ethertype | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Metadata length | TLV encoded Metadata | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | TLV encoded Metadata ~~~..............~~ | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Original Ethernet payload ~~................~~ | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 7: Packet format suggestion 546 An outer Ethernet header is introduced to carry the information on 547 Destination FEID, Source FEID and optional NEID. 549 o The Outer Destination MAC Address carries the Destination FEID 550 identification. 552 o Outer Source MAC Address carries the Source FEID identification. 554 o When an NEID is needed, an optional 802.1Q is carried with 12-bit 555 VLANid representing the NEID. 557 o The ethernet type is used to identify the frame as inter-FE LFB 558 type. Ethertype 0xFEFE is to be used (XXX: to be requested). 560 o The 16-bit metadata length is used to described the total encoded 561 metadata length (including the 16 bits used to encode the metadata 562 length). 564 o One or more TLV encoded metadatum follows the metadata length 565 field. The TLV type identifies the Metadata id. ForCES IANA- 566 defined Metadata ids will be used. We recognize that using a 16 567 bit TLV restricts the metadata id to 16 bits instead of ForCES 568 define space of 32 bits. However, at the time of publication we 569 believe this is sufficient to carry all the info we need and 570 approach taken would save us 4 bytes per Metadatum transferred. 571 XXX: If there is objection from the we could convert this to an 572 ILV. 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 complementing 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. MTU 592 setting can be achieved by configuration or ForCES control of 593 the port LFB. In essence, the control plane making a decision 594 for the MTU settings of the egress port is implicitly deciding 595 how much metadata will be allowed. 597 o The frame may be dropped if there is congestion on the receiving 598 FE side. One approach to mitigate this issue is to make sure that 599 inter-FE LFB frames receive the highest priority treatment when 600 scheduled on the wire. Typically protocols that tunnel in the 601 middle box do not care and depend on the packet originator to 602 resend if the originator cares about reliability. We do not 603 expect to be any different. 605 o While we expect to use a unique IEEE-issued ethertype for the 606 inter-FE traffic, we use lessons learnt from VXLAN deployment[XXX: 607 ref] to be more flexible on the settings of the ethertype value 608 used. We make the etherype an LFB read-write component. Linux 609 VXLAN implementation uses UDP port 8472 because the deployment 610 happened much earlier than the point of RFC publication where the 611 IANA assigned udp port issued was 4789. For this reason we make 612 it possible to define at control time what ethertype to use and 613 default to the IEEE issued ethertype. We justify this by assuming 614 that a given ForCES NE is likely to be owned by a single 615 organization and that the organization's CE(or CE cluster) could 616 program all participating FEs via the inter-FE LFB (described in 617 this document) to recognize a private ethernet type used for 618 inter-LFB traffic (possibly those defined as available for private 619 use by the IEEE, namely: IDs 0x88B5 and 0x88B6) 621 6. Detailed Description of the Ethernet inter-FE LFB 623 The ethernet inter-FE LFB has two LFB input ports and three LFB 624 output ports. 626 +-----------------+ 627 Inter-FE LFB | | 628 Encapsulated | OUT2+--> decapsulated Packet + metadata 629 -------------->|IN2 | 630 Packet | | 631 | | 632 raw Packet + | OUT1+--> encapsulated Packet 633 -------------->|IN1 | 634 Metadata | | 635 | EXCEPTIONOUT +--> ExceptionID, packet + metadata 636 | | 637 +-----------------+ 639 Figure 8: Inter-FE LFB 641 6.1. Data Handling 643 The Inter-FE LFB can be positioned at the egress of a source FE. In 644 such a case an Inter-FE LFB instance receives via port IN1, raw 645 packet and metadata IDs from the preceeding LFB instance. The 646 InterFEid metadatum MAY be present on the incoming raw data. The 647 processed encapsulated packet will go out on either LFB port OUT1 to 648 a downstream LFB or EXCEPTIONOUT port in the case of a failure. 650 The Inter-FE LFB can be positioned at the ingress of a receiving FE. 651 In such a case an Inter-FE LFB receives, via port IN2, an 652 encapsulated packet. Successful processing of the packet will result 653 in a raw packet with associated metadata IDs going downstream to an 654 LFB connected on OUT2. On failure the data is sent out EXCEPTIONOUT. 656 The Inter-FE LFB may use the InterFEid metadatum on egress of an FE 657 to lookup the IFETable table. The interFEid in such a case will be 658 generated by an upstream LFB instance (i.e one preceeding the 659 Inter-FE LFB). The output result constitutes a matched table row 660 which has the InterFEinfo details i.e. the tuple {NEID,Destination 661 FEID,Source FEID, inter FE type, metafilters}. The metafilters lists 662 define which Metadatum are to be passed to the neighboring FE. 664 6.1.1. Egress Processing 666 The egress Inter-FE LFB will receive an ethernet frame and 667 accompanying metadatum (including optionally the InterFEid metadatum) 668 at LFB port IN1. The ethernet frame may be 802.1Q tagged. 670 The InterFEid may be used to lookup IFETable table. If lookup is 671 successful, the inter-FE LFB will perform the following actions using 672 the resulting tuple: 674 o Increment statistics for packet and byte count observed. 676 o Walk each passed metadatum apply against the MetaFilterList. If 677 no legitimate metadata is found that needs to be passed downstream 678 then the processing stops and the packet is allowed through as is. 680 o check that the additional overhead of the outer header and 681 encapsulated metadata will not exceed MTU. If it does increment 682 the error packet count statistics and return allowing the packet 683 to pass through. (XXX: Should it be dropped because it cannot 684 send the required metadata?) 686 o create the outer ethernet header which is a duplicate of the 687 incoming frame's ethernet header. The outer ethernet header may 688 have an optional 802.1q header (if one was included in the 689 original frame). 691 o If the NEID field is present (not 0) and the original header had a 692 vlan tag, replace the vlan tag on the outer header with the value 693 from the matched NEID field. If the NEID field is present (not 0) 694 and the original header did not have a vlan tag, create one that 695 matches the NEID field and appropriately add it to the outer 696 header. If the NEID field is absent or 0, do nothing. 698 o If the optional DSTFE is present, set the Destination MAC address 699 of the outer header with value found in the DSTFE field. When 700 absent, then the inner destination MAC address is used (at this 701 point already copied). 703 o If the optional SRCFE is present, set the Source MAC address of 704 the outer header with value found in the SRCFE field. If SRCFE is 705 absent then the inner source MAC address is used (at this point 706 already copied). 708 o If the optional IFETYPE is present, set the outer ethernet type to 709 the value found in IFETYPE. If IFETYPE is absent then the 710 standard ethernet type is used (XXX: to be requested from IEEE). 712 o encapsulate each allowed metadatum in a TLV. Use the Metaid as 713 the "type" field in the TLV header. The TLV should be aligned to 714 32 bits. This means you may need to add padding of zeroes to 715 ensure alignment. 717 o Update the Metadata length to the sum of each TLV's space + 2 718 bytes (for the Metadata length field 16 bit space). 720 The resulting packet is sent to the next LFB instance connected to 721 the OUT1 LFB-port; typically a port LFB. 723 In the case of a failed lookup or a zero-value InterFEid, (or absence 724 of InterFEid when needed by the implementation) the packet is sent 725 out unchanged via the OUT1 LFB Class instance port (typically towards 726 a Port LFB). 728 6.1.2. Ingress Processing 730 An inter-FE LFB packet is recognized by looking at the etherype 731 received on LFB instance port IN2. The IFETable table may be 732 optionally utilized to provide metadata filters (XXX: Should we allow 733 for the interFEid metadata to be sent by the neighbor FE and use it 734 here? Implementations dont need it to associate a specific port/MAC/ 735 VLAN etc with the IFETable LFB). 737 o Increment statistics for packet and byte count observed. 739 o The inter-FE LFB instance looks at the metadata length field and 740 walks the packet data extracting from the TLVs the metadata 741 values. For each metadatum extracted, optionally the metaid is 742 compared against the relevant IFETable row metafilter list. If 743 the metadatum is recognized and is allowed by the filter the 744 corresponding implementation metadatum field is set. If an 745 unknown metadatum id is encountered, or if the metaid is not found 746 in the option allowed filter list the implementation is expected 747 to ignore it, increment the packet error statistic and proceed 748 processing other metadatum. 750 o Upon completion of processing all the metadata, the inter-FE LFB 751 instance resets the header to point to the original (inner) 752 ethernet header i.e skips the metadata information. At this point 753 the the original ethernet frame that was passed to the egress 754 Inter-FE LFB at the source FE is reconstructed. This data is then 755 passed along with the reconstructed metadata downstream to the 756 next LFB instance in the graph. 758 In the case of processing failure of either ingress or egress 759 positioning of the LFB, the packet and metadata are sent out the 760 EXCEPTIONOUT LFB port with proper error id (XXX: More description to 761 be added). 763 6.2. Components 765 There are two LFB component populated by the CE. 767 The CE optionally programs LFB instances in a service graph that 768 require inter-FE connectivity with InterFEid values to correspond to 769 the inter-FE LFB IFETable table entries to use. 771 The first component is an array known as the IFETable table. The 772 array rows are made up of IFEInfo structure. The IFEInfo structure 773 constitutes: optional NEID, optional IFETYPE, optional Destination 774 FEID(DSTFE), optional Source FEID (SRCFE), optional array of allowed 775 Metaids (MetaFilterList). The table is looked up by a 32 bit index 776 passed from an upstream LFB class instance in the form of InterFEid 777 metadatum. 779 The second component(ID 2) is IFEStats table which carries the basic 780 stats structure bstats. The table index value used to lookup this 781 table is the same one as in IFETable table; in other words for a 782 table row index 10 in the IFETable table, its corresponding stats 783 will be found in row index of the IFEStats table. 785 6.3. Inter-FE LFB XML Model 787 XXX: metadata definition requires clarification. We expect to use 788 IANA defined metadatum. How do we describe them here in the 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 807 809 810 bstats 811 Basic stats 812 813 814 bytes 815 The total number of bytes seen 816 uint64 817 819 820 packets 821 The total number of packets seen 822 uint32 823 825 826 errors 827 The total number of packets with errors 828 uint32 829 830 832 834 835 IFEInfo 836 Describing IFE table row Information 837 838 839 NEID 840 841 The VLAN Id 12 bits part of the 802.1q TCI field. 842 843 844 uint16 845 846 847 IFETYPE 848 849 the ethernet type to be used for outgoing IFE frame 850 851 852 uint16 853 854 855 DSTFE 856 857 the destination MAC address of destination FE 858 859 860 byte[6] 861 862 863 SRCFE 864 865 the source MAC address used for the source FE 866 867 868 byte[6] 869 870 871 MetaFilterList 872 873 the metadata filter table 874 875 876 877 uint32 878 879 881 882 884 886 887 888 InterFEid 889 890 Metadata identifying the index of the NexFE table 891 892 16 893 uint32 894 895 897 898 899 IFE 900 901 This LFB describes IFE connectivity parametrization 903 904 1.0 906 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 956 957 OUT2 958 959 The output port of the Ingress side. 960 961 962 963 EthernetAny 964 965 966 InterFEid 967 968 969 971 972 EXCEPTIONOUT 973 974 The exception handling path 975 976 977 978 EthernetAny 979 980 981 ExceptionID 982 InterFEid 983 984 985 987 989 991 992 IFETable 993 994 the table of all InterFE relations 995 996 997 IFEInfo 998 1000 1001 1002 IFEStats 1003 1004 the stats corresponding to the IFETable table 1005 1006 bstats 1007 1009 1011 1012 1013 1015 Figure 9: Inter-FE LFB XML 1017 7. Acknowledgements 1019 The authors would like to thank Joel Halpern and Dave Hood for the 1020 stimulating discussions. Evangelos Haleplidis contributed to 1021 improving this document. 1023 8. IANA Considerations 1025 This memo includes two IANA requests within the registry 1026 https://www.iana.org/assignments/forces 1028 The first request is for the sub-registry "Logical Functional Block 1029 (LFB) Class Names and Class Identifiers" to request for the 1030 reservation of LFB class name IFE with LFB classid 6112 with version 1031 1.0. 1033 The second request is for the sub-registry "Metadata ID" to request 1034 for the InterFEid metadata the value 0x00000010. 1036 9. Security Considerations 1038 XXX:TBD 1040 10. References 1041 10.1. Normative References 1043 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1044 "Forwarding and Control Element Separation (ForCES) 1045 Framework", RFC 3746, April 2004. 1047 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 1048 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 1049 Control Element Separation (ForCES) Protocol 1050 Specification", RFC 5810, March 2010. 1052 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 1053 Layer (TML) for the Forwarding and Control Element 1054 Separation (ForCES) Protocol", RFC 5811, March 2010. 1056 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 1057 Element Separation (ForCES) Forwarding Element Model", 1058 RFC 5812, March 2010. 1060 10.2. Informative References 1062 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1063 Requirement Levels", BCP 14, RFC 2119, March 1997. 1065 Authors' Addresses 1067 Damascane M. Joachimpillai 1068 Verizon 1069 60 Sylvan Rd 1070 Waltham, Mass. 02451 1071 USA 1073 Email: damascene.joachimpillai@verizon.com 1075 Jamal Hadi Salim 1076 Mojatatu Networks 1077 Suite 400, 303 Moodie Dr. 1078 Ottawa, Ontario K2H 9R4 1079 Canada 1081 Email: hadi@mojatatu.com