idnits 2.17.1 draft-ietf-forces-lfb-lib-07.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 12, 2012) is 4486 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: 'N' is mentioned on line 510, but not defined == Unused Reference: 'RFC1812' is defined on line 4387, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 4396, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 4399, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 4403, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Wang 3 Internet-Draft Zhejiang Gongshang University 4 Intended status: Standards Track E. Haleplidis 5 Expires: July 15, 2012 University of Patras 6 K. Ogawa 7 NTT Corporation 8 C. Li 9 Hangzhou H3C Tech. Co., Ltd. 10 J. Halpern 11 Ericsson 12 January 12, 2012 14 ForCES Logical Function Block (LFB) Library 15 draft-ietf-forces-lfb-lib-07 17 Abstract 19 This document defines basic classes of Logical Function Blocks (LFBs) 20 used in the Forwarding and Control Element Separation (ForCES). The 21 basic LFB classes are defined according to ForCES FE model and ForCES 22 protocol specifications, and are scoped to meet requirements of 23 typical router functions and considered as the basic LFB library for 24 ForCES. The library includes the descriptions of the LFBs and the 25 XML definitions. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 15, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1. Scope of the Library . . . . . . . . . . . . . . . . . . 8 66 3.2. Overview of LFB Classes in the Library . . . . . . . . . 10 67 3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . 10 68 3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 10 69 3.2.3. Sample LFB Class Application . . . . . . . . . . . . 12 70 3.3. Document Structure . . . . . . . . . . . . . . . . . . . 13 71 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.1.2. Compound struct . . . . . . . . . . . . . . . . . . . 16 75 4.1.3. Compound array . . . . . . . . . . . . . . . . . . . 16 76 4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 17 77 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 17 78 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 18 79 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 40 80 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 40 81 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 41 82 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 43 83 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 44 84 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 47 85 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 49 86 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 50 87 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 50 88 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 52 89 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 53 90 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 54 91 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 56 92 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 58 93 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 60 94 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 62 95 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 62 96 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 63 97 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 64 98 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 64 99 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 65 100 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 68 101 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 90 102 7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 90 103 7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 91 104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 94 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 107 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 96 108 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 98 109 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 98 110 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 99 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 101 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 102 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 102 114 12.2. Informative References . . . . . . . . . . . . . . . . . 102 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 117 1. Terminology and Conventions 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2. Definitions 127 This document follows the terminology defined by the ForCES protocol 128 in [RFC5810] and by the ForCES FE model in [RFC5812]. The 129 definitions below are repeated for clarity. 131 Control Element (CE) - A logical entity that implements the ForCES 132 protocol and uses it to instruct one or more FEs on how to process 133 packets. CEs handle functionality such as the execution of 134 control and signaling protocols. 136 Forwarding Element (FE) - A logical entity that implements the 137 ForCES protocol. FEs use the underlying hardware to provide per- 138 packet processing and handling as directed/controlled by one or 139 more CEs via the ForCES protocol. 141 ForCES Network Element (NE) - An entity composed of one or more 142 CEs and one or more FEs. To entities outside an NE, the NE 143 represents a single point of management. Similarly, an NE usually 144 hides its internal organization from external entities. 146 LFB (Logical Function Block) - The basic building block that is 147 operated on by the ForCES protocol. The LFB is a well defined, 148 logically separable functional block that resides in an FE and is 149 controlled by the CE via ForCES protocol. The LFB may reside at 150 the FE's datapath and process packets or may be purely an FE 151 control or configuration entity that is operated on by the CE. 152 Note that the LFB is a functionally accurate abstraction of the 153 FE's processing capabilities, but not a hardware-accurate 154 representation of the FE implementation. 156 FE Model - The FE model is designed to model the logical 157 processing functions of an FE, which is defined by the ForCES FE 158 model document [RFC5812]. The FE model proposed in this document 159 includes three components; the LFB modeling of individual Logical 160 Functional Block (LFB model), the logical interconnection between 161 LFBs (LFB topology), and the FE-level attributes, including FE 162 capabilities. The FE model provides the basis to define the 163 information elements exchanged between the CE and the FE in the 164 ForCES protocol [RFC5810]. 166 FE Topology - A representation of how the multiple FEs within a 167 single NE are interconnected. Sometimes this is called inter-FE 168 topology, to be distinguished from intra-FE topology (i.e., LFB 169 topology). 171 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. 172 An LFB Instance represents an LFB Class (or Type) existence. 173 There may be multiple instances of the same LFB Class (or Type) in 174 an FE. An LFB Class is represented by an LFB Class ID, and an LFB 175 Instance is represented by an LFB Instance ID. As a result, an 176 LFB Class ID associated with an LFB Instance ID uniquely specifies 177 an LFB existence. 179 LFB Metadata - Metadata is used to communicate per-packet state 180 from one LFB to another, but is not sent across the network. The 181 FE model defines how such metadata is identified, produced and 182 consumed by the LFBs. It defines the functionality but not how 183 metadata is encoded within an implementation. 185 LFB Component - Operational parameters of the LFBs that must be 186 visible to the CEs are conceptualized in the FE model as the LFB 187 components. The LFB components include, for example, flags, 188 single parameter arguments, complex arguments, and tables that the 189 CE can read and/or write via the ForCES protocol (see below). 191 LFB Topology - Representation of how the LFB instances are 192 logically interconnected and placed along the datapath within one 193 FE. Sometimes it is also called intra-FE topology, to be 194 distinguished from inter-FE topology. 196 Data Path - A conceptual path taken by packets within the 197 forwarding plane inside an FE. Note that more than one data path 198 can exist within an FE. 200 ForCES Protocol - While there may be multiple protocols used 201 within the overall ForCES architecture, the term "ForCES protocol" 202 and "protocol" refer to the Fp reference points in the ForCES 203 Framework in [RFC3746]. This protocol does not apply to CE-to-CE 204 communication, FE-to-FE communication, or to communication between 205 FE and CE managers. Basically, the ForCES protocol works in a 206 master-slave mode in which FEs are slaves and CEs are masters. 207 This document defines the specifications for this ForCES protocol. 209 LFB Port - A port refers to an LFB input port or output port. See 210 Section 3.2 of [RFC5812] for more detailed definitions. 212 Physical Port - A port refers to a physical media input port or 213 output port of an FE. A physical port is usually assigned with a 214 physical port ID, abbreviated with a PHYPortID. This document 215 mainly deals with physical ports with Ethernet media. 217 Logical Port - A conceptually virtual port at data link layer (L2) 218 or network layer (L3). A logical port is usually assigned with a 219 logical port ID, abbreviated with a LogicalPortID. The logical 220 ports can be further categorized with a L2 logical port or a L3 221 logical port. An L2 logical port can be assigned with a L2 222 logical port ID, abbreviated with a L2PortID. An L3 logical port 223 can be assigned with a L3 logical port ID, abbreviated with a 224 L3PortID. MAC layer VLAN ports belongs to L2 logical ports as 225 well as logical ports. 227 LFB Class Library - The LFB class library is a set of LFB classes 228 that has been identified as the most common functions found in 229 most FEs and hence should be defined first by the ForCES Working 230 Group. The LFB Class Library is defined by this document. 232 3. Introduction 234 [RFC5810] specifies Forwarding and Control Element Separation 235 (ForCES) framework. In the framework, Control Elements (CEs) 236 configure and manage one or more separate Forwarding Elements (FEs) 237 within a Network Element (NE) by use of a ForCES protocol. [RFC5810] 238 specifies the ForCES protocol. [RFC5812] specifies the Forwarding 239 Element (FE) model. In the model, resources in FEs are described by 240 classes of Logical Function Blocks (LFBs). The FE model defines the 241 structure and abstract semantics of LFBs, and provides XML schema for 242 the definitions of LFBs. 244 This document conforms to the specifications of the FE model 245 [RFC5812] and specifies detailed definitions of classes of LFBs, 246 including detailed XML definitions of LFBs. These LFBs form a base 247 LFB library for ForCES. LFBs in the base library are expected to be 248 combined to form an LFB topology for a typical router to implement IP 249 forwarding. It should be emphasized that an LFB is an abstraction of 250 functions rather than its implementation details. The purpose of the 251 LFB definitions is to represent functions so as to provide 252 interoperability between separate CEs and FEs. 254 More LFB classes with more functions may be developed in future time 255 and documented by IETF. Vendors may also develop proprietary LFB 256 classes as described in the FE model [RFC5812]. 258 3.1. Scope of the Library 260 It is intended that the LFB classes described in this document are 261 designed to provide the functions of a typical router. [RFC5812] 262 specifies that a typical router is expected to provide functions to: 264 (1) Interface to packet networks and implement the functions 265 required by that network. These functions typically include: 267 * Encapsulating and decapsulating the IP datagrams with the 268 connected network framing (e.g., an Ethernet header and 269 checksum), 271 * Sending and receiving IP datagrams up to the maximum size 272 supported by that network, this size is the network's Maximum 273 Transmission Unit or MTU, 275 * Translating the IP destination address into an appropriate 276 network-level address for the connected network (e.g., an 277 Ethernet hardware address), if needed, and 279 * Responding to network flow control and error indications, if 280 any. 282 (2) Conform to specific Internet protocols including the Internet 283 Protocol (IPv4 and/or IPv6), Internet Control Message Protocol 284 (ICMP), and others as necessary. 286 (3) Receive and forward Internet datagrams. Important issues in 287 this process are buffer management, congestion control, and 288 fairness. 290 * Recognizes error conditions and generates ICMP error and 291 information messages as required. 293 * Drops datagrams whose time-to-live fields have reached zero. 295 * Fragments datagrams when necessary to fit into the MTU of the 296 next network. 298 (4) Choose a next-hop destination for each IP datagram, based on the 299 information in its routing database. 301 (5) Usually support an interior gateway protocol (IGP) to carry out 302 distributed routing and reachability algorithms with the other 303 routers in the same autonomous system. In addition, some 304 routers will need to support an exterior gateway protocol (EGP) 305 to exchange topological information with other autonomous 306 systems. For all routers, it is essential to provide ability to 307 manage static routing items. 309 (6) Provide network management and system support facilities, 310 including loading, debugging, status reporting, exception 311 reporting and control. 313 The classical IP router utilizing the ForCES framework constitutes a 314 CE running some controlling IGP and/or EGP function or static route 315 setup and FEs implementing using Logical Function Blocks (LFBs) 316 conforming to the FE model[RFC5812] specifications. The CE, in 317 conformance to the ForCES protocol[RFC5810] and the FE model 318 [RFC5812] specifications, instructs the LFBs on the FE how to treat 319 received/sent packets. 321 Packets in an IP router are received and transmitted on physical 322 media typically referred to as "ports". Different physical port 323 media will have different ways for encapsulating outgoing frames and 324 decapsulating incoming frames. The different physical media will 325 also have different attributes that influence its behavior and how 326 frames get encapsulated or decapsulated. This document will only 327 deal with Ethernet physical media. Other future documents may deal 328 with other types of media. This document will also interchangeably 329 refer to a port to be an abstraction that constitutes a PHY and a MAC 330 as described by the LFBs like EtherPHYCop, EtherMACIn, and 331 EtherMACOut. 333 IP packets emanating from port LFBs are then processed by a 334 validation LFB before being further forwarded to the next LFB. After 335 the validation process the packet is passed to an LFB where IP 336 forwarding decision is made. In the IP Forwarding LFBs, a Longest 337 Prefix Match LFB is used to look up the destination information in a 338 packet and select a next hop index for sending the packet onward. A 339 next hop LFB uses the next hop index metadata to apply the proper 340 headers to the IP packets, and direct them to the proper egress. 341 Note that in the process of IP packets processing, in this document, 342 we are adhering to the weak-host model [RFC1122] since that is the 343 most usable model for a packet processing Network Element. 345 3.2. Overview of LFB Classes in the Library 347 It is critical to classify functional requirements into various 348 classes of LFBs and construct a typical but also flexible enough base 349 LFB library for various IP forwarding equipments. 351 3.2.1. LFB Design Choices 353 A few design principles were factored into choosing how the base LFBs 354 looked like. These are: 356 o if a function can be designed by either one LFB or two or more 357 LFBs with the same cost, the choice is to go with two or more LFBs 358 so as to provide more flexibility for implementers. 360 o when flexibility is not required, an LFB should take advantage of 361 its independence as much as possible and have minimal coupling 362 with other LFBs. The coupling may be from LFB attributes 363 definitions as well as physical implementations. 365 o unless there is a clear difference in functionality, similar 366 packet processing should not be represented as two or more 367 different LFBs. Or else, it may add extra burden on 368 implementation to achieve interoperability. 370 3.2.2. LFB Class Groupings 372 The document defines groups of LFBs for typical router function 373 requirements: 375 (1) A group of Ethernet processing LFBs are defined to abstract the 376 packet processing for Ethernet as the port media type. As the 377 most popular media type with rich processing features, Ethernet 378 media processing LFBs was a natural choice. Definitions for 379 processing of other port media types like POS or ATM may be 380 incorporated in the library in future version of the document or 381 in a future separate document. The following LFBs are defined 382 for Ethernet processing: 384 * EtherPHYCop (Section 5.1.1) 386 * EtherMACIn (Section 5.1.2) 388 * EtherClassifier (Section 5.1.3) 390 * EtherEncap (Section 5.1.4) 392 * EtherMACOut (Section 5.1.5) 394 (2) A group of LFBs are defined for IP packet validation process. 395 The following LFBs are defined for IP validation processing: 397 * IPv4Validator (Section 5.2.1) 399 * IPv6Validator (Section 5.2.2) 401 (3) A group of LFBs are defined to abstract IP forwarding process. 402 The following LFBs are defined for IP forwarding processing: 404 * IPv4UcastLPM (Section 5.3.1) 406 * IPv4NextHop (Section 5.3.2) 408 * IPv6UcastLPM (Section 5.3.3) 410 * IPv6NextHop (Section 5.3.4) 412 (4) A group of LFBs are defined to abstract the process for redirect 413 operation, i.e., data packet transmission between CE and FEs. 414 The following LFBs are defined for redirect processing: 416 * RedirectIn (Section 5.4.1) 418 * RedirectOut (Section 5.4.2) 420 (5) A group of LFBs are defined for abstracting some general purpose 421 packet processing. These processing processes are usually 422 general to many processing locations in an FE LFB topology. The 423 following LFBs are defined for redirect processing: 425 * BasicMetadataDispatch (Section 5.5.1) 427 * GenericScheduler (Section 5.5.2) 429 3.2.3. Sample LFB Class Application 431 Although Section 7 will present use cases for LFBs defined in this 432 document, this section shows a sample LFB class application in 433 advance so that readers can get a quick overlook of the LFB classes 434 with the usage. 436 Figure 1 shows the typical LFB processing path for an IPv4 unicast 437 forwarding case with Ethernet media interfaces. To focus on the IP 438 forwarding function, some inputs or outputs of LFBs in the figure 439 that are not related to the function are ignored. Section 7.1 will 440 describe the figure in details. 442 +-----+ +------+ 443 | | | | 444 | |<---------------|Ether |<----------------------------+ 445 | | |MACOut| | 446 | | | | | 447 |Ether| +------+ | 448 |PHY | | 449 |Cop | +---+ | 450 |#1 | +-----+ | |----->IPv6 Packets | 451 | | | | | | | 452 | | |Ether| | | IPv4 Packets | 453 | |->|MACIn|-->| |-+ +----+ | 454 +-----+ | | | | | | |---> Multicast Packets | 455 +-----+ +---+ | | | +-----+ +---+ | 456 Ether +->| |------->| | | | | 457 . Classifier| | |Unicast |IPv4 | | | | 458 . | | |Packets |Ucast|->| |--+ | 459 . | +----+ |LPM | | | | | 460 +---+ | IPv4 +-----+ +---+ | | 461 +-----+ | | | Validator IPv4 | | 462 | | | | | NextHop| | 463 +-----+ |Ether| | |-+ IPv4 Packets | | 464 | |->|MACIn|-->| | | | 465 | | | | | |----->IPv6 Packets | | 466 |Ether| +-----+ +---+ | | 467 |PHY | Ether +----+ | | 468 |Cop | Classifier | | +-------+ | | 469 |#n | +------+ | | |Ether | | | 470 | | | | | |<--|Encap |<-+ | 471 | | | |<------| | | | | 472 | |<---------------|Ether | ...| | +-------+ | 473 | | |MACOut| +---| | | 474 | | | | | +----+ | 475 +-----+ +------+ | BasicMetadataDispatch | 476 +-------------------------+ 478 Figure 1: LFB use case for IPv4 forwarding 480 3.3. Document Structure 482 Base type definitions, including data types, packet frame types, and 483 metadata types are presented in advance for definitions of various 484 LFB classes. Section 4 (Base Types section) provides a description 485 on the base types used by this LFB library. To enable extensive use 486 of these base types by other LFB class definitions, the base type 487 definitions are provided as a separate library. 489 Within every group of LFB classes, a set of LFBs are defined for 490 individual function purposes. Section 5 (LFB Class Descriptions 491 section) provides text descriptions on the individual LFBs. Note 492 that for a complete definition of an LFB, a text description as well 493 as a XML definition is required. 495 LFB classes are finally defined by XML with specifications and schema 496 defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB 497 Definitions section) provides the complete XML definitions of the 498 base LFB classes library. 500 Section 7 provides several use cases on how some typical router 501 functions can be implemented using the base LFB library defined in 502 this document. 504 4. Base Types 506 The FE model [RFC5812] has specified predefined (built-in) atomic 507 data-types as below: 509 char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], 510 string, byte[N], boolean, octetstring[N], float16, float32, float64. 512 Based on the atomic data types and with the use of type definition 513 elements in the FE model XML schema, new data types, packet frame 514 types, and metadata types can be defined. 516 To define a base LFB library for typical router functions, a set of 517 base data types, frame types, and metadata types should be defined. 518 This section provides a brief description of the base types and a 519 full XML definition of them as well. 521 The base type XML definitions are provided with a separate XML 522 library file named "BaseTypeLibrary". Users can refer to this 523 library by the statement: 525 527 4.1. Data Types 529 Data types defined in the base type library are categorized by types 530 of atomic, compound struct, and compound array. 532 4.1.1. Atomic 534 The following data types are defined as atomic data types and put in 535 the base type library: 537 Data Type Name Brief Description 538 -------------- ----------------- 539 IPv4Addr IPv4 address 540 IPv6Addr IPv6 address 541 IEEEMAC IEEE MAC address 542 LANSpeedType Network speed values 543 DuplexType Duplex types 544 PortStatusValues The possible values of port status, used for 545 both administrative and operative status 546 VlanIDType The type of VLAN ID 547 VlanPriorityType The type of VLAN priority 548 SchdDisciplineType Scheduling discipline type 550 4.1.2. Compound struct 552 The following compound struct types are defined in the base type 553 library: 555 Data Type Name Brief Description 556 -------------- ----------------- 557 EtherDispatchEntryType Entry type for Ethernet dispatch table 558 VlanInputTableEntryType Entry type for VLAN input table 559 EncapTableEntryType Entry type for Ethernet encapsulation table 560 MACInStatsType Statistics type for EtherMACIn LFB 561 MACOutStatsType Statistics type for EtherMACOut LFB 562 EtherClassifyStatsType Entry type for statistics table in 563 EtherClassifier LFB 564 IPv4PrefixInfoType Entry type for IPv4 prefix table 565 IPv6PrefixInfoType Entry type for IPv6 prefix table 566 IPv4NextHopInfoType Entry type for IPv4 next hop table 567 IPv6NextHopInfoType Entry type for IPv6 next hop table 568 IPv4ValidatorStatsType Statistics type in IPv4validator LFB 569 IPv6ValidatorStatsType Statistics type in IPv6validator LFB 570 IPv4UcastLPMStatsType Statistics type in IPv4Unicast LFB 571 IPv6UcastLPMStatsType Statistics type in IPv6Unicast LFB 572 QueueStatsType Entry type for queue depth table 573 MetadataDispatchType Entry type for metadata dispatch table 575 4.1.3. Compound array 577 Compound array types are mostly created based on compound struct 578 types for LFB table components. The following compound array types 579 are defined in this base type library: 581 Data Type Name Brief Description 582 -------------- ----------------- 583 EtherClassifyStatsTableType Type for Ethernet classifier statistics 584 information table 585 EtherDispatchTableType Type for Ethernet dispatch table 586 VlanInputTableType Type for VLAN input table 587 EncapTableType Type for Ethernet encapsulation table 588 IPv4PrefixTableType Type for IPv4 prefix table 589 IPv6PrefixTableType Type for IPv6 prefix table 590 IPv4NextHopTableType Type for IPv4 next hop table 591 IPv6NextHopTableType Type for IPv6 next hop table 592 MetadataDispatchTableType Type for Metadata dispatch table 593 QueueStatsTableType Type for Queue depth table 595 4.2. Frame Types 597 According to FE model [RFC5812], frame types are used in LFB 598 definitions to define packet frame types both an LFB expects at its 599 input port and the LFB emits at its output port. The 600 element in the FE model is used to define a new frame type. 602 The following frame types are defined in the base type library: 604 Frame Name Brief Description 605 -------------- ---------------- 606 EthernetII An Ethernet II frame 607 ARP An ARP packet 608 IPv4 An IPv4 packet 609 IPv6 An IPv6 packet 610 IPv4Unicast An IPv4 unicast packet 611 IPv4Multicast An IPv4 multicast packet 612 IPv6Unicast An IPv6 unicast packet 613 IPv6Multicast An IPv6 multicast packet 614 Arbitrary Any types of packet frames 616 4.3. MetaData Types 618 LFB Metadata is used to communicate per-packet state from one LFB to 619 another. The element in the FE model is used to define 620 a new metadata type. 622 The following metadata types are currently defined in the base type 623 library. 625 Metadata Name Metadata ID Brief Description 626 ------------ ---------- ------------- 627 PHYPortID 1 The ingress physical port that the packet 628 arrived on 629 SrcMAC 2 Source MAC address of the packet 630 DstMAC 3 Destination MAC address of the packet 631 LogicalPortID 4 ID of a logical port for the packet 632 EtherType 5 The packet's Ethernet type 633 VlanID 6 The VLAN ID of the Ethernet packet 634 VlanPriority 7 The priority of the Ethernet packet 635 NexthopIPv4Addr 8 Nexthop IPv4 address the packet is sent to 636 NexthopIPv6Addr 9 Nexthop IPv6 address the packet is sent to 637 HopSelector 10 A search key the packet can use to look up 638 a nexthop table for next hop information 639 of the packet 640 ExceptionID 11 Indicating exception type of the packet 641 which is exceptional for some processing 642 ValidateErrorID 12 Indicating error type of the packet failed 643 some validation process 644 L3PortID 13 ID of L3 port 645 RedirectIndex 14 A metadata CE sends to RedirectIn LFB for 646 the associated packet to select output 647 port in the LFB group output "PktsOut" 648 MediaEncapInfoIndex 15 A search key the packet uses to look up a 649 media encapsulation table to select its 650 encapsulation media as well as followed 651 encapsulation LFB 653 4.4. XML for Base Type Library 655 656 659 660 661 EthernetAll 662 All kinds of Ethernet frame 663 664 665 EthernetII 666 An Ethernet II frame 667 668 669 ARP 670 An arp packet 671 672 673 IPv4 674 An IPv4 packet 675 676 677 IPv6 678 An IPv6 packet 679 680 681 IPv4Unicast 682 An IPv4 unicast packet 683 684 685 IPv4Multicast 686 An IPv4 multicast packet 687 688 689 IPv6Unicast 690 An IPv6 unicast packet 691 692 693 IPv6Multicast 694 An IPv6 multicast packet 695 696 697 Arbitrary 698 Any types of packet frames 699 700 701 702 703 IPv4Addr 704 IPv4 address 705 byte[4] 706 707 708 IPv6Addr 709 IPv6 address 710 byte[16] 711 712 713 IEEEMAC 714 IEEE MAC address. 715 byte[6] 716 717 718 LANSpeedType 719 Network speed values 720 721 uint32 722 723 724 LAN_SPEED_10M 725 10M Ethernet 726 727 728 LAN_SPEED_100M 729 100M Ethernet 730 731 732 LAN_SPEED_1G 733 1000M Ethernet 734 735 736 LAN_SPEED_10G 737 10G Ethernet 738 739 740 LAN_SPEED_AUTO 741 LAN speed auto 742 743 744 745 746 747 DuplexType 748 Duplex types 749 750 uint32 751 752 753 Auto 754 Auto negotitation. 755 756 757 Half-duplex 758 port negotitation half duplex 759 760 761 Full-duplex 762 port negotitation full duplex 763 764 765 766 767 768 PortStatusValues 769 The possible values of port status, used for both 770 administrative and operative status. 771 772 uchar 773 774 775 Disabled 776 the port is operatively disabled. 777 778 779 UP 780 the port is up. 781 782 783 Down 784 The port is down. 785 786 787 788 789 790 MACInStatsType 791 Statistics type in EtherMACIn LFB. 792 793 794 NumPacketsReceived 795 The number of packets received. 796 uint64 797 798 799 NumPacketsDropped 800 The number of packets dropped. 801 uint64 802 803 804 805 806 MACOutStatsType 807 Statistics type in EtherMACOut LFB. 808 809 810 NumPacketsTransmitted 811 The number of packets transmitted. 812 uint64 813 814 815 NumPacketsDropped 816 The number of packets dropped. 817 uint64 818 819 820 821 822 EtherDispatchEntryType 823 Entry type for Ethernet dispatch table in 824 EtherClassifier LFB. 825 826 827 LogicalPortID 828 Logical port ID. 829 uint32 830 831 832 EtherType 833 The EtherType value in the Ether head. 834 835 uint32 836 837 838 LFBOutputSelectIndex 839 LFB Group output port index to select 840 downstream LFB port. Some possibilities of downstream 841 LFB instances are: 842 a) IPv4Validator 843 b) IPv6Validator 844 c) RedirectOut 845 d) etc 846 Note: LFBOutputSelectIndex is the FromPortIndex for 847 the port group "ClassifyOut" in the table LFBTopology 848 (of FEObject LFB) as defined for the EtherClassifier 849 LFB. 850 uint32 851 852 853 854 855 EtherDispatchTableType 856 Type for Ethernet dispatch table.This table is used 857 in EtherClassifier LFB. Every Ethernet packet can be 858 dispatched to the LFB output group ports according to the 859 logical port ID. 860 861 EtherDispatchEntryType 862 863 864 865 VlanIDType 866 The type of VLAN ID 867 868 uint16 869 870 871 872 873 874 875 VlanPriorityType 876 The type of VLAN priority. 877 878 uchar 879 880 881 882 883 884 885 VlanInputTableEntryType 886 Entry type for VLAN input table in EtherClassifier 887 LFB. 888 889 890 IncomingPortID 891 The incoming port ID. 892 uint32 893 894 895 VlanID 896 Vlan ID. 897 VlanIDType 898 899 900 LogicalPortID 901 logical port ID. 902 uint32 903 904 905 906 907 VlanInputTableType 908 Type for VLAN input table.This table is used 909 in EtherClassifier LFB. Every Ethernet packet can get a new 910 LogicalPortID according to the IncomingPortID and VlanID. 911 912 913 VlanInputTableEntryType 914 915 916 917 EtherClassifyStatsType 918 Entry type for statistics table in EtherClassifier 919 LFB. 920 921 922 EtherType 923 The EtherType value 924 uint32 925 926 927 PacketsNum 928 Packets number 929 uint64 930 931 932 933 934 EtherClassifyStatsTableType 935 Type for Ethernet classifier statistics 936 information table in EtherClassifier LFB. 937 938 EtherClassifyStatsType 939 940 941 942 IPv4ValidatorStatsType 943 Statistics type in IPv4validator LFB. 944 945 946 badHeaderPkts 947 Number of bad header packets. 948 uint64 949 950 951 badTotalLengthPkts 952 Number of bad total length packets. 953 uint64 954 955 956 badTTLPkts 957 Number of bad TTL packets. 958 uint64 959 960 961 badChecksumPkts 962 Number of bad checksum packets. 963 uint64 964 965 966 967 968 IPv6ValidatorStatsType 969 Statistics type in IPv6validator LFB. 970 971 972 badHeaderPkts 973 Number of bad header packets. 974 uint64 975 976 977 badTotalLengthPkts 978 Number of bad total length packets. 979 uint64 980 981 982 badHopLimitPkts 983 Number of bad Hop limit packets. 984 uint64 985 986 987 988 989 IPv4PrefixInfoType 990 Entry type for IPv4 prefix table. 991 992 993 IPv4Address 994 An IPv4 Address 995 IPv4Addr 996 997 998 Prefixlen 999 The prefix length 1000 1001 uchar 1002 1003 1004 1005 1006 1007 1008 HopSelector 1009 HopSelector is the nexthop ID which points to 1010 the nexthop table 1011 uint32 1012 1013 1014 ECMPFlag 1015 An ECMP Flag for this route 1016 1017 boolean 1018 1019 1020 False 1021 This route does not have multiple 1022 nexthops. 1023 1024 1025 True 1026 This route has multiple nexthops. 1027 1028 1029 1030 1031 1032 1033 DefaultRouteFlag 1034 A default route flag. 1035 1036 boolean 1037 1038 1039 False 1040 This is not a default route. 1041 1042 1043 1044 True 1045 This route is a default route. 1046 1047 1048 1049 1050 1051 1052 1053 1054 IPv4PrefixTableType 1055 Type for IPv4 prefix table. This table is currently 1056 used in IPv4UcastLPM LFB. The LFB uses the destination IPv4 1057 address of every input packet as search key to look up this 1058 table in order extract a next hop selector. 1059 1060 IPv4PrefixInfoType 1061 1062 1063 1064 IPv4UcastLPMStatsType 1065 Statistics type in IPv4Unicast LFB. 1066 1067 1068 InRcvdPkts 1069 The total number of input packets received. 1070 1071 uint64 1072 1073 1074 FwdPkts 1075 IPv4 packets forwarded by this LFB 1076 uint64 1077 1078 1079 NoRoutePkts 1080 The number of IP datagrams discarded because 1081 no route could be found. 1082 uint64 1083 1084 1085 1086 1087 IPv6PrefixInfoType 1088 Entry type for IPv6 prefix table. 1089 1090 1091 IPv6Address 1092 An IPv6 Address 1093 IPv6Addr 1094 1095 1096 Prefixlen 1097 The prefix length 1098 1099 uchar 1100 1101 1102 1103 1105 1106 1107 HopSelector 1108 HopSelector is the nexthop ID which points 1109 to the nexthop table 1110 uint32 1111 1112 1113 ECMPFlag 1114 An ECMP Flag for this route 1115 1116 boolean 1117 1118 1119 False 1120 This route does not have multiple 1121 nexthops. 1122 1123 1124 True 1125 This route has multiple nexthops. 1126 1127 1128 1129 1130 1131 1132 DefaultRouteFlag 1133 A Default Route Flag. 1134 1135 boolean 1136 1137 1138 False 1139 This is not a default route. 1140 1141 1142 1143 True 1144 This route is a default route. 1145 1146 1147 1148 1149 1150 1151 1152 1153 IPv6PrefixTableType 1154 Type for IPv6 prefix table.This table is currently 1155 used in IPv6UcastLPM LFB. The LFB uses the destination IPv6 1156 address of every input packet as search key to look up this 1157 table in order extract a next hop selector. 1158 1159 IPv6PrefixInfoType 1160 1161 1162 1163 IPv6UcastLPMStatsType 1164 Statistics type in IPv6Unicast LFB. 1165 1166 1167 InRcvdPkts 1168 The total number of input packets 1169 received 1170 uint64 1171 1172 1173 FwdPkts 1174 IPv6 packets forwarded by this LFB 1175 uint64 1176 1177 1178 NoRoutePkts 1179 The number of IP datagrams discarded because 1180 no route could be found. 1181 uint64 1182 1183 1184 1185 1186 IPv4NextHopInfoType 1187 Entry type for IPv4 next hop table. 1188 1189 1190 L3PortID 1191 The ID of the Logical/physical Output Port 1192 that we pass onto the downstream LFB instance. This 1193 ID indicates what port to the neighbor is as defined 1194 by L3. 1195 uint32 1196 1197 1198 MTU 1199 Maximum Transmission Unit for out going port. 1200 It is for desciding whether the packet need 1201 fragmentation 1202 uint32 1203 1204 1205 NextHopIPAddr 1206 Next Hop IPv4 Address 1207 IPv4Addr 1208 1209 1210 MediaEncapInfoIndex 1211 The index we pass onto the downstream LFB 1212 instance. This index is used to lookup a table 1213 (typically media encapsulatation related) further 1214 downstream. 1215 uint32 1216 1217 1218 LFBOutputSelectIndex 1219 LFB Group output port index to select 1220 downstream LFB port. Some possibilities of downstream 1221 LFB instances are: 1222 a) EtherEncap 1223 b) Other type of media LFB 1224 c) A metadata Dispatcher 1225 d) A redirect LFB 1226 e) etc 1227 Note: LFBOutputSelectIndex is the FromPortIndex for 1228 the port group "SuccessOut" in the table LFBTopology 1229 (of FEObject LFB) as defined for the IPv4NextHop LFB. 1230 1231 uint32 1232 1233 1234 1235 1236 IPv4NextHopTableType 1237 Type for IPv4 next hop table. This table is used 1238 in IPv4NextHop LFB. The LFB uses metadata "HopSelector" 1239 received to match the array index to get the next hop 1240 information. 1241 1242 IPv4NextHopInfoType 1243 1244 1245 1246 IPv6NextHopInfoType 1247 Entry type for IPv6 next hop table. 1248 1249 1250 L3PortID 1251 The ID of the Logical/physical Output Port 1252 that we pass onto the downstream LFB instance. This 1253 ID indicates what port to the neighbor is as defined 1254 by L3. 1255 uint32 1256 1257 1258 MTU 1259 Maximum Transmission Unit for out going port. 1260 It is for desciding whether the packet need 1261 fragmentation. 1262 uint32 1263 1264 1265 NextHopIPAddr 1266 Next Hop IPv6 Address 1267 IPv6Addr 1268 1269 1270 MediaEncapInfoIndex 1271 The index we pass onto the downstream LFB 1272 instance. This index is used to lookup a table 1273 (typically media encapsulatation related) further 1274 downstream. 1275 uint32 1276 1277 1278 LFBOutputSelectIndex 1279 LFB Group output port index to select 1280 downstream LFB port. Some possibilities of downstream 1281 LFB instances are: 1282 a) EtherEncap 1283 b) Other type of media LFB 1284 c) A metadata Dispatcher 1285 d) A redirect LFB 1286 e) etc 1287 Note: LFBOutputSelectIndex is the FromPortIndex for 1288 the port group "SuccessOut" in the table LFBTopology 1289 (of FEObject LFB) as defined for the IPv6NextHop LFB. 1290 1291 uint32 1292 1293 1294 1295 1296 IPv6NextHopTableType 1297 Type for IPv6 next hop table. This table is used 1298 in IPv6NextHop LFB. The LFB uses metadata "HopSelector" 1299 received to match the array index to get the next hop 1300 information. 1301 1302 IPv6NextHopInfoType 1303 1304 1305 1306 EncapTableEntryType 1307 Entry type for Ethernet encapsulation table in 1308 EtherEncap LFB. 1309 1310 1311 DstMac 1312 Ethernet Mac of the Neighbor 1313 IEEEMAC 1314 1315 1316 SrcMac 1317 Source MAC used in encapsulation 1318 IEEEMAC 1319 1320 1321 VlanID 1322 VLAN ID. 1323 VlanIDType 1324 1325 1326 L2PortID 1327 Output logical L2 port ID. 1328 uint32 1329 1330 1331 1332 1333 EncapTableType 1334 Type for Ethernet encapsulation table. This 1335 table is used in EtherEncap LFB. The LFB uses the metadata 1336 "MediaEncapInfoIndex " received to get the encapsulation 1337 information. 1338 1339 EncapTableEntryType 1340 1341 1342 1343 MetadataDispatchType 1344 Entry type for Metadata dispatch table in 1345 BasicMetadataDispatch LFB. 1346 1347 1348 MetadataValue 1349 metadata value. 1350 uint32 1351 1352 1353 OutputIndex 1354 group output port index. 1355 uint32 1356 1357 1358 1359 1360 MetadataDispatchTableType 1361 Type for Metadata dispatch table. This table is used 1362 in BasicMetadataDispatch LFB. The LFB uses MetadataValue to 1363 get the LFB group output port index. 1364 1365 MetadataDispatchType 1366 1367 MetadataValue 1368 1369 1370 1371 1372 SchdDisciplineType 1373 Scheduling discipline type. 1374 1375 uint32 1376 1377 1378 RR 1379 Round Robin scheduler. 1380 1381 1382 1383 1384 1385 QueueStatsType 1386 Entry type for queue statistics table in 1387 GenericScheduler LFB. 1388 1389 1390 QueueID 1391 Queue ID 1392 uint32 1394 1395 1396 QueueDepthInPackets 1397 the Queue Depth when the depth units 1398 are packets. 1399 uint32 1400 1401 1402 QueueDepthInBytes 1403 the Queue Depth when the depth units 1404 are bytes. 1405 uint32 1406 1407 1408 1409 1410 QueueStatsTableType 1411 Type for Queue statistics table in GenericScheduler 1412 LFB. 1413 1414 QueueDepthType 1415 1416 1417 1418 1419 1420 PHYPortID 1421 The physical port ID that a packet has entered. 1422 1423 1 1424 uint32 1425 1426 1427 SrcMAC 1428 Source MAC address of the packet. 1429 2 1430 IEEEMAC 1431 1432 1433 DstMAC 1434 Destination MAC address of the packet. 1435 3 1436 IEEEMAC 1437 1438 1439 LogicalPortID 1440 ID of a logical port for the packet. 1441 4 1442 uint32 1443 1444 1445 EtherType 1446 Indicating the Ethernet type of the Ethernet packet. 1447 1448 5 1449 uint32 1450 1451 1452 VlanID 1453 The Vlan ID of the Ethernet packet. 1454 6 1455 VlanIDType 1456 1457 1458 VlanPriority 1459 The priority of the Ethernet packet. 1460 7 1461 VlanPriorityType 1462 1463 1464 NexthopIPv4Addr 1465 Nexthop IPv4 address the packet is sent to. 1466 1467 8 1468 IPv4Addr 1469 1470 1471 NexthopIPv6Addr 1472 Nexthop IPv6 address the packet is sent to. 1473 1474 9 1475 IPv6Addr 1476 1477 1478 HopSelector 1479 A search key the packet can use to look up a nexthop 1480 table for next hop information of the packet. 1481 10 1482 uint32 1483 1484 1485 ExceptionID 1486 Indicating exception type of the packet which is 1487 exceptional for some processing. 1488 11 1489 1490 uint32 1491 1492 1493 AnyUnrecognizedExceptionCase 1494 any unrecognized exception case. 1495 1496 1497 ClassifyNoMatching 1498 There is no matching when classifying the 1499 packet in EtherClassifier LFB. 1500 1501 1502 MediaEncapInfoIndexInvalid 1503 The MediaEncapInfoIndex value of the 1504 packet is invalid and can not be allocated in the 1505 EncapTable. 1506 1507 1508 EncapTableLookupFailed 1509 The packet failed lookup of the EncapTable 1510 table even though the MediaEncapInfoIndex is valid. 1511 1512 1513 1514 BadTTL 1515 Packet with expired TTL. 1516 1517 1518 IPv4HeaderLengthMismatch 1519 Packet with header length more than 5 1520 words. 1521 1522 1523 RouterAlertOptions 1524 Packet IP head include Router Alert 1525 options. 1526 1527 1528 IPv6HopLimitZero 1529 Packet with Hop Limit zero 1530 1531 1532 IPv6NextHeaderHBH 1533 Packet with next header set to Hop-by-Hop 1534 1535 1536 1537 SrcAddressExecption 1538 Packet with exceptional source address. 1539 1540 1541 1542 DstAddressExecption 1543 Packet with exceptional destination 1544 address 1545 1546 1547 LPMLookupFailed 1548 The packet failed the LPM lookup of the 1549 prefix table. 1550 1551 1552 HopSelectorInvalid 1553 The HopSelector for the packet is invalid. 1554 1555 1556 1557 NextHopLookupFailed 1558 The packet failed lookup of the NextHop 1559 table even though the HopSelector is valid. 1560 1561 1562 1563 FragRequired 1564 The MTU for outgoing interface is less 1565 than the packet size. 1566 1567 1568 MetadataNoMatching 1569 There is no matching when looking up the 1570 metadata dispatch table. 1571 1572 1573 1574 1575 1576 ValidateErrorID 1577 Indicating error type of the packet failed some 1578 validation process. 1579 12 1580 1581 uint32 1582 1583 1584 AnyUnrecognizedValidateErrorCase 1585 Any unrecognized validate error case. 1587 1588 1589 1590 InvalidIPv4PacketSize 1591 Packet size reported is less than 20 1592 bytes. 1593 1594 1595 NotIPv4Packet 1596 Packet is not IP version 4. 1597 1598 1599 InvalidIPv4HeaderLengthSize 1600 Packet with header length less than 1601 5 words. 1602 1603 1604 InvalidIPv4LengthFieldSize 1605 Packet with total length field less than 1606 20 bytes. 1607 1608 1609 InvalidIPv4Checksum 1610 Packet with invalid checksum. 1611 1612 1613 InvalidIPv4SrcAddr 1614 Packet with invalid source address. 1615 1616 1617 1618 InvalidIPv4DstAddr 1619 Packet with source address 0. 1620 1621 1622 InvalidIPv6PacketSize 1623 Packet size reported is less than 40 1624 bytes. 1625 1626 1627 NotIPv6Packet 1628 Packet is not IP version 6. 1629 1630 1631 InvalidIPv6SrcAddr 1632 Packet with invalid source address. 1633 1634 1635 1636 InvalidIPv6DstAddr 1637 Packet with invalid destination address. 1638 1639 1640 1641 1642 1643 1644 L3PortID 1645 ID of L3 port. See the definition in 1646 IPv4NextHopInfoType. 1647 13 1648 uint32 1649 1650 1651 RedirectIndex 1652 metadata CE sends to RedirectIn LFB for the 1653 associated packet to select output port in the LFB group 1654 output "PktsOut". 1655 14 1656 uint32 1657 1658 1659 MediaEncapInfoIndex 1660 A search key the packet uses to look up a media 1661 encapsulation table to select its encapsulation media as 1662 well as followed encapsulation LFB. 1663 15 1664 uint32 1665 1666 1667 1669 5. LFB Class Description 1671 According to ForCES specifications, LFB (Logical Function Block) is a 1672 well defined, logically separable functional block that resides in an 1673 FE, and is a functionally accurate abstraction of the FE's processing 1674 capabilities. An LFB Class (or type) is a template that represents a 1675 fine-grained, logically separable aspect of FE processing. Most LFBs 1676 are related to packet processing in the data path. LFB classes are 1677 the basic building blocks of the FE model. Note that [RFC5810] has 1678 already defined an 'FE Protocol LFB' which is a logical entity in 1679 each FE to control the ForCES protocol. [RFC5812] has already 1680 defined an 'FE Object LFB'. Information like the FE Name, FE ID, FE 1681 State, LFB Topology in the FE are represented in this LFB. 1683 As specified in Section 3.1, this document focuses on the base LFB 1684 library for implementing typical router functions, especially for IP 1685 forwarding functions. As a result, LFB classes in the library are 1686 all base LFBs to implement router forwarding. 1688 In this section, the terms "upstream LFB" and "downstream LFB" are 1689 used. These are used relative to an LFB to an LFB that is being 1690 described. An "upstream LFB" is one whose output ports are connected 1691 to input ports of the LFB under consideration such that output 1692 (typically packets with metadata) can be sent from the "upstream LFB" 1693 to the LFB under consideration. Similarly, a "downstream LFB" whose 1694 input ports are connected to output ports of the LFB under 1695 consideration such that the LFB under consideration can send 1696 information to the "downstream LFB". Note that in some rare 1697 topologies, an LFB may be both upstream and downstream relative to 1698 another LFB. 1700 Also note that, as a default provision of [RFC5812], in FE model, all 1701 metadata produced by upstream LFBs will pass through all downstream 1702 LFBs by default without being specified by input port or output port. 1703 Only those metadata that will be used (consumed) by an LFB will be 1704 explicitly marked in input of the LFB as expected metadata. For 1705 instance, in downstream LFBs of a physical layer LFB, even there is 1706 no specific metadata expected, metadata like PHYPortID produced by 1707 the physical layer LFB will always pass through all downstream LFBs 1708 regardless of whether the metadata has been expected by the LFBs or 1709 not. 1711 5.1. Ethernet Processing LFBs 1713 As the most popular physical and data link layer protocols, Ethernet 1714 is widely deployed. It becomes a basic requirement for a router to 1715 be able to process various Ethernet data packets. 1717 Note that there exist different versions of Ethernet formats, like 1718 Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP. 1719 There also exist varieties of LAN techniques based on Ethernet, like 1720 various VLANs, MACinMAC, etc. Ethernet processing LFBs defined here 1721 are intended to be able to cope with all these variations of Ethernet 1722 technology. 1724 There are also various types of Ethernet physical interface media. 1725 Among them, copper and fiber media may be the most popular ones. As 1726 a base LFB definition and a starting point, the document only defines 1727 an Ethernet physical LFB with copper media. For other media 1728 interfaces, specific LFBs may be defined in the future versions of 1729 the library. 1731 5.1.1. EtherPHYCop 1733 EtherPHYCop LFB abstracts an Ethernet interface physical layer with 1734 media limited to copper. 1736 5.1.1.1. Data Handling 1738 This LFB is the interface to the Ethernet physical media. The LFB 1739 handles ethernet frames coming in from or going out of the FE. 1740 Ethernet frames sent and received cover all packets encapsulated with 1741 different versions of Ethernet protocols, like Ethernet V2, 802.3 1742 RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets 1743 encapsulated with varieties of LAN techniques based on Ethernet, like 1744 various VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll 1745 frame type has been introduced. 1747 Ethernet frames are received from the physical media port and passed 1748 downstream to LFBs such as EtherMACIn via a singleton output known as 1749 "EtherPHYOut". A 'PHYPortID' metadata, to indicate which physical 1750 port the frame came into from the external world, is passed along 1751 with the frame. 1753 Ethernet packets are received by this LFB from upstream LFBs such as 1754 EtherMacOut LFBs via the singleton input known as "EtherPHYIn" before 1755 being sent out onto the external world. 1757 5.1.1.2. Components 1759 The AdminStatus component is defined for CE to administratively 1760 manage the status of the LFB. The CE may administratively startup or 1761 shutdown the LFB by changing the value of AdminStatus. The default 1762 value is set to 'Down'. 1764 An OperStatus component captures the physical port operational 1765 status. A PHYPortStatusChanged event is defined so the LFB can 1766 report to the CE whenever there is an operational status change of 1767 the physical port. 1769 The PHYPortID component is a unique identification for a physical 1770 port. It is defined as 'read-only' by CE. Its value is enumerated 1771 by FE. The component will be used to produce a 'PHYPortID' metadata 1772 at the LFB output and to associate it to every Ethernet packet this 1773 LFB receives. The metadata will be handed to downstream LFBs for 1774 them to use the PHYPortID. 1776 A group of components are defined for link speed management. The 1777 AdminLinkSpeed is for CE to configure link speed for the port and the 1778 OperLinkSpeed is for CE to query the actual link speed in operation. 1779 The default value for the AdminLinkSpeed is set to auto-negotiation 1780 mode. 1782 A group of components are defined for duplex mode management. The 1783 AdminDuplexMode is for CE to configure proper duplex mode for the 1784 port and the OperDuplexMode is for CE to query the actual duplex mode 1785 in operation. The default value for the AdminDuplexMode is set to 1786 auto-negotiation mode. 1788 A CarrierStatus component captures the status of the carrier and 1789 specifies whether the port link is operationally up. The default 1790 value for the CarrierStatus is 'false'. 1792 5.1.1.3. Capabilities 1794 The capability information for this LFB includes the link speeds that 1795 are supported by the FE (SupportedLinkSpeed) as well as the supported 1796 duplex modes (SupportedDuplexMode). 1798 5.1.1.4. Events 1800 Several events are generated. There is an event for changes in the 1801 status of the physical port (PhyPortStatusChanged). Such an event 1802 will notify that the physical port status has been changed and the 1803 report will include the new status of the physical port. 1805 Another event captures changes in the operational link speed 1806 (LinkSpeedChanged). Such an event will notify the CE that the 1807 operational speed has been changed and the report will include the 1808 new negotiated operational speed. 1810 A final event captures changes in the duplex mode 1811 (DuplexModeChanged). Such an event will notify the CE that the 1812 duplex mode has been changed and the report will include the new 1813 negotiated duplex mode. 1815 5.1.2. EtherMACIn 1817 EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. 1818 This LFB describes Ethernet processing functions like MAC address 1819 locality check, deciding if the Ethernet packets should be bridged, 1820 providing Ethernet layer flow control, etc. 1822 5.1.2.1. Data Handling 1824 The LFB is expected to receive all types of Ethernet packets, via a 1825 singleton input known as "EtherPktsIn", which are usually output from 1826 some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside 1827 with a metadata indicating the physical port ID that the packet 1828 arrived on. 1830 The LFB is defined with two separate singleton outputs. All Output 1831 packets are emitted in the original ethernet format received at the 1832 physical port, unchanged, and cover all types of ethernet types. 1834 The first singleton output is known as "NormalPathOut". It usually 1835 outputs Ethernet packets to some LFB like an EtherClassifier LFB for 1836 further L3 forwarding process alongside with a PHYPortID metadata 1837 indicating which physical port the packet came from. 1839 The second singleton output is known as "L2BridgingPathOut". 1840 Although the LFB library this document defines is basically to meet 1841 typical router functions, it will attempt to be forward compatible 1842 with future router functions. The "L2BridgingPathOut" is defined to 1843 meet the requirement that L2 bridging functions may be optionally 1844 supported simultaneously with L3 processing and some L2 bridging LFBs 1845 that may be defined in the future. If the FE supports L2 bridging, 1846 the CE can enable or disable it by means of a "L2BridgingPathEnable" 1847 component in the FE. If it is enabled, by also instantiating some L2 1848 bridging LFB instances following the L2BridgingPathOut, FEs are 1849 expected to fulfill L2 bridging functions. L2BridgingPathOut will 1850 output packets exactly the same as that in the NormalPathOut output. 1852 This LFB can be set to work in a Promiscuous Mode, allowing all 1853 packets to pass through the LFB without being dropped. Otherwise, a 1854 locality check will be performed based on the local MAC addresses. 1855 All packets that do not pass through the locality check will be 1856 dropped. 1858 This LFB participates in Ethernet flow control in cooperation with 1859 EtherMACOut LFB. This document does not go into the details of how 1860 this is implemented; the reader may refer to some relevant 1861 references. This document also does not describe how the buffers 1862 which induce the flow control messages behave - it is assumed that 1863 such artifacts exist and describing them is out of scope in this 1864 document. 1866 5.1.2.2. Components 1868 The AdminStatus component is defined for the CE to administratively 1869 manage the status of the LFB. The CE may administratively startup or 1870 shutdown the LFB by changing the value of AdminStatus. The default 1871 value is set to 'Down'. 1873 The LocalMACAddresses component specifies the local MAC addresses 1874 based on which locality checks will be made. This component is an 1875 array of MAC addresses, and of 'read-write' access permission. 1877 An L2BridgingPathEnable component captures whether the LFB is set to 1878 work as a L2 bridge. An FE that does not support bridging will 1879 internally set this flag to false, and additionally set the flag 1880 property as read-only. The default value for is 'false'. 1882 The PromiscuousMode component specifies whether the LFB is set to 1883 work as in a promiscuous mode. The default value for is 'false'. 1885 The TxFlowControl component defines whether the LFB is performing 1886 flow control on sending packets. The default value for is 'false'. 1888 The RxFlowControl component defines whether the LFB is performing 1889 flow control on receiving packets. The default value for is 'false'. 1891 A struct component, MACInStats, defines a set of statistics for this 1892 LFB, including the number of received packets and the number of 1893 dropped packets. 1895 5.1.2.3. Capabilities 1897 This LFB does not have a list of capabilities. 1899 5.1.2.4. Events 1901 This LFB does not have any events specified. 1903 5.1.3. EtherClassifier 1905 EtherClassifier LFB abstracts the process to decapsulate Ethernet 1906 packets and then classify them. 1908 5.1.3.1. Data Handling 1910 This LFB describes the process of decapsulating Ethernet packets and 1911 classifying them into various network layer data packets according to 1912 information included in the Ethernet packets headers. 1914 The LFB is expected to receive all types of Ethernet packets, via a 1915 singleton input known as "EtherPktsIn", which are usually output from 1916 an upstream LFB like EtherMACIn LFB. This input is also capable of 1917 multiplexing to allow for multiple upstream LFBs being connected. 1918 For instance, when L2 bridging function is enabled in EtherMACIn LFB, 1919 some L2 bridging LFBs may be applied. In this case, some Ethernet 1920 packets after L2 processing may have to be input to EtherClassifier 1921 LFB for classification, while simultaneously packets directly output 1922 from EtherMACIn may also need to input to this LFB. This input is 1923 capable of handling such a case. Usually, all expected Ethernet 1924 Packets will be associated with a PHYPortID metadata, indicating the 1925 physical port the packet comes from. In some cases, for instance, 1926 like in a MACinMAC case, a LogicalPortID metadata may be expected to 1927 associate with the Ethernet packet to further indicate which logical 1928 port the Ethernet packet belongs to. Note that PHYPortID metadata is 1929 always expected while LogicalPortID metadata is optionally expected. 1931 Two output LFB ports are defined. 1933 The first output is a group output port known as "ClassifyOut". 1934 Types of network layer protocol packets are output to instances of 1935 the port group. Because there may be various types of protocol 1936 packets at the output ports, the produced output frame is defined as 1937 arbitrary for the purpose of wide extensibility in the future. 1938 Metadata to be carried along with the packet data is produced at this 1939 LFB for consumption by downstream LFBs. The metadata passed 1940 downstream includes PHYPortID, as well as information on Ethernet 1941 type, source MAC address, destination MAC address and the logical 1942 port ID. .If the original packet is a VLAN packet and contains a VLAN 1943 ID and a VLAN priority value, then the VLAN ID and the VLAN priority 1944 value are also carried downstream as metadata. As a result, the VLAN 1945 ID and priority metadata are defined with the availability of 1946 "conditional". 1948 The second output is a singleton output port known as "ExceptionOut", 1949 which will output packets for which the data processing failed, along 1950 with an additional ExceptionID metadata to indicate what caused the 1951 exception. Currently defined exception types include: 1953 o There is no matching when classifying the packet. 1955 Usually the exception out port may point to no where, indicating 1956 packets with exceptions are dropped, while in some cases, the output 1957 may be pointed to the path to the CE for further processing, 1958 depending on individual implementations. 1960 5.1.3.2. Components 1962 An EtherDispatchTable array component is defined in the LFB to 1963 dispatch every Ethernet packet to the output group according to the 1964 logical port ID assigned by the VlanInputTable to the packet and the 1965 Ethernet type in the Ethernet packet header. Each row of the array 1966 is a struct containing a Logical Port ID, an EtherType and an Output 1967 Index. With the CE configuring the dispatch table, the LFB can be 1968 expected to classify various network layer protocol type packets and 1969 output them at different output ports. It is expected that the LFB 1970 classify packets according to protocols like IPv4, IPv6, MPLS, ARP, 1971 ND, etc. 1973 A VlanInputTable array component is defined in the LFB to classify 1974 VLAN Ethernet packets. Each row of the array is a struct containing 1975 an Incoming Port ID, a VLAN ID and a Logical Port ID. According to 1976 IEEE VLAN specifications, all Ethernet packets can be recognized as 1977 VLAN types by defining that if there is no VLAN encapsulation in a 1978 packet, a case with VLAN tag 0 is considered. Every input packet is 1979 assigned with a new LogicalPortID according to the packet incoming 1980 port ID and the VLAN ID. A packet incoming port ID is defined as a 1981 logical port ID if a logical port ID is associated with the packet, 1982 or a physical port ID if no logical port ID associated. The VLAN ID 1983 is exactly the VLAN ID in the packet if it is a VLAN packet, or 0 if 1984 it is not. Note that a logical port ID of a packet may be rewritten 1985 with a new one by the VlanInputTable processing. 1987 Note that the logical port ID and physical port ID mentioned above 1988 are all originally configured by CE, and are globally effective 1989 within a ForCES NE (Network Element). To distinguish a physical port 1990 ID from a logical port ID in the incoming port ID field of the 1991 VlanInputTable, physical port ID and logical port ID must be assigned 1992 with separate number spaces. 1994 An array component, EtherClassifyStats, defines a set of statistics 1995 for this LFB, measuring the number of packets per EtherType. Each 1996 row of the array is a struct containing an EtherType and a Packet 1997 number. 1999 5.1.3.3. Capabilities 2001 This LFB does not have a list of capabilities. 2003 5.1.3.4. Events 2005 This LFB has no events specified. 2007 5.1.4. EtherEncap 2009 The EtherEncap LFB abstracts the process to replace or attach 2010 appropriate Ethernet headers to the packet. 2012 5.1.4.1. Data Handling 2014 This LFB abstracts the process of encapsulating Ethernet headers onto 2015 received packets. The encapsulation is based on passed metadata. 2017 The LFB is expected to receive IPv4 and IPv6 packets, via a singleton 2018 input port known as "EncapIn" which may be connected to an upstream 2019 LFB like an IPv4NextHop, an IPv6NextHop, BasicMetadataDispatch, or 2020 any LFB which requires to output packets for Ethernet encapsulation. 2021 The LFB always expects from upstream LFBs the MediaEncapInfoIndex 2022 metadata which is used as a search key to lookup the Encapsulation 2023 Table. An input packet may also optionally receive a VLAN priority 2024 metadata, indicating that the packet is originally with a priority 2025 value. The priority value will be loaded back to the packet when 2026 encapsulating. The optional VLAN priority metadata is defined with a 2027 default value 0. 2029 Two singleton output LFB ports are defined. 2031 The first singleton output known as "SuccessOut". Upon a successful 2032 table lookup, the destination and source MAC addresses, and the 2033 logical media port (L2PortID) are found in the matching table entry. 2034 The CE may set the VlanID in case VLANs are used. By default the 2035 table entry for VlanID of 0 is used as per IEEE rules. Whatever the 2036 value of VlanID is, if the input metadata VlanPriority is non-zero, 2037 the packet will have a VLAN tag. If the VlanPriority and the VlanID 2038 are all zero, there is no VLAN tag to this packet. After replacing 2039 or attaching the appropriate Ethernet headers to the packet is 2040 complete, the packet is passed out on the "SuccessOut" LFB port to a 2041 downstream LFB instance alongside with the L2PortID. 2043 The second singleton output known as "ExceptionOut", which will 2044 output packets for which the table lookup fails, along with an 2045 additional ExceptionID metadata. Currently defined exception types 2046 only include the following case: 2048 o The MediaEncapInfoIndex value of the packet is invalid and can not 2049 be allocated in the EncapTable. 2051 o The packet failed lookup of the EncapTable table even though the 2052 MediaEncapInfoIndex is valid. 2054 The upstream LFB may be programmed by the CE to pass along a 2055 MediaEncapInfoIndex that does not exist in the EncapTable. That is 2056 to allow for resolution of the L2 headers, if needed, to be made at 2057 the L2 encapsulation level in this case (Ethernet) via ARP, or ND (or 2058 other methods depending on the link layer technology) when a table 2059 miss occurs. 2061 For neighbor L2 header resolution(table miss exception), the 2062 processing LFB may pass this packet to the CE via the redirect LFB or 2063 FE software or another LFB instance for further resolution. In such 2064 a case the metadata NexthopIPv4Addr or NexthopIPv6Addr generated by 2065 Nexthop LFB is also passed to the exception handling. Such an IP 2066 address could be used to do activities such as ARP or ND by the 2067 handler it is passed to. 2069 The result of the L2 resolution is to update the EncapTable as well 2070 as the Nexthop LFB so subsequent packets do not fail EncapTable 2071 lookup. The EtherEncap LFB does not make any assumptions of how the 2072 EncapTable is updated by the CE (or whether ARP/ND is used 2073 dynamically or static maps exist). 2075 Downstream LFB instances could be either an EtherMACOut type or a 2076 BasicMetadataDispatch type. If the final packet L2 processing is 2077 possible to be on per-media-port basis or resides on a different FE 2078 or in cases where L2 header resolution is needed, then the model 2079 makes sense to use a BasicMetadataDispatch LFB to fanout to different 2080 LFB instances. If there is a direct egress port point, then the 2081 model makes sense to have a downstream LFB instance being an 2082 EtherMACOut. 2084 5.1.4.2. Components 2086 This LFB has only one component named EncapTable which is defined as 2087 an array. Each row of the array is a struct containing the 2088 destination MAC address, the source MAC address, the VLAN ID with a 2089 default value of zero and the output logical L2 port ID. 2091 5.1.4.3. Capabilities 2093 This LFB does not have a list of capabilities. 2095 5.1.4.4. Events 2097 This LFB does not have any events specified. 2099 5.1.5. EtherMACOut 2101 EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. 2102 This LFB describes Ethernet packet output process. Ethernet output 2103 functions are closely related to Ethernet input functions, therefore 2104 many components defined in this LFB are as aliases of EtherMACIn LFB 2105 components. 2107 5.1.5.1. Data Handling 2109 The LFB is expected to receive all types of Ethernet packets, via a 2110 singleton input known as "EtherPktsIn", which are usually output from 2111 an Ethernet encapsulation LFB, alongside with a metadata indicating 2112 the physical port ID that the packet will go through. 2114 The LFB is defined with a singleton output. All Output packets are 2115 in Ethernet format, possibly with various Ethernet types, alongside 2116 with a metadata indicating the physical port ID the packet is to go 2117 through. This output links to a downstream LFB that is usually an 2118 Ethernet physical LFB like EtherPHYcop LFB. 2120 This LFB participates in Ethernet flow control in cooperation with 2121 EtherMACIn LFB. This document does not go into the details of how 2122 this is implemented; the reader may refer to some relevant 2123 references. This document also does not describe how the buffers 2124 which induce the flow control messages behave - it is assumed that 2125 such artifacts exist and describing them is out of scope in this 2126 document. 2128 Note that as a base definition, functions like multiple virtual MAC 2129 layers are not supported in this LFB version. It may be supported in 2130 the future by defining a subclass or a new version of this LFB. 2132 5.1.5.2. Components 2134 The AdminStatus component is defined for CE to administratively 2135 manage the status of the LFB. The CE may administratively startup or 2136 shutdown the LFB by changing the value of AdminStatus. The default 2137 value is set to 'Down'. Note that this component is defined as an 2138 alias of the AdminStatus component in the EtherMACIn LFB. This 2139 infers that an EtherMACOut LFB usually coexists with an EtherMACIn 2140 LFB, both of which share the same administrative status management by 2141 CE. Alias properties as defined in the ForCES FE model [RFC5812] 2142 will be used by CE to declare the target component this alias refers, 2143 which include the target LFB class and instance IDs as well as the 2144 path to the target component. 2146 The MTU component defines the maximum transmission unit. 2148 The TxFlowControl component defines whether the LFB is performing 2149 flow control on sending packets. The default value for is 'false'. 2150 Note that this component is defined as an alias of TxFlowControl 2151 component in the EtherMACIn LFB. 2153 The RxFlowControl component defines whether the LFB is performing 2154 flow control on receiving packets. The default value for is 'false'. 2155 Note that this component is defined as an alias of RxFlowControl 2156 component in the EtherMACIn LFB. 2158 A struct component, MACOutStats, defines a set of statistics for this 2159 LFB, including the number of transmitted packets and the number of 2160 dropped packets. 2162 5.1.5.3. Capabilities 2164 This LFB does not have a list of capabilities. 2166 5.1.5.4. Events 2168 This LFB does not have any events specified. 2170 5.2. IP Packet Validation LFBs 2172 The LFBs are defined to abstract IP packet validation process. An 2173 IPv4Validator LFB is specifically for IPv4 protocol validation and an 2174 IPv6Validator LFB for IPv6. 2176 5.2.1. IPv4Validator 2178 The IPv4Validator LFB performs IPv4 packets validation according to 2179 [RFC5812]. 2181 5.2.1.1. Data Handling 2183 This LFB performs IPv4 validation according to [RFC5812]. The IPv4 2184 packet will be output to the corresponding LFB port the indication 2185 whether the packet is unicast, multicast or whether an exception has 2186 occurred or the validation failed. 2188 This LFB always expects, as input, packets which have been indicated 2189 as IPv4 packets by an upstream LFB, like an EtherClassifier LFB. 2190 There is no specific metadata expected by the input of the LFB. 2192 Four output LFB ports are defined. 2194 All validated IPv4 unicast packets will be output at the singleton 2195 port known as "IPv4UnicastOut". All validated IPv4 multicast packets 2196 will be output at the singleton port known as "IPv4MulticastOut" 2197 port. 2199 A singleton port known as "ExceptionOut" is defined to output packets 2200 which have been validated as exception packets. An exception ID 2201 metadata is produced to indicate what has caused the exception. An 2202 exception case is the case when a packet needs further processing 2203 before being normally forwarded. Currently defined exception types 2204 include: 2206 o Packet with expired TTL 2208 o Packet with header length more than 5 words 2210 o Packet IP head including Router Alert options 2212 o Packet with exceptional source address 2214 o Packet with exceptional destination address 2216 Note that although TTL is checked in this LFB for validity, 2217 operations like TTL decrement are made by the downstream forwarding 2218 LFB. 2220 The final singleton port known as "FailOut" is defined for all 2221 packets which have errors and failed the validation process. An 2222 error case is the case when a packet is unable to be further 2223 processed nor forwarded except being dropped. An error ID is 2224 associated a packet to indicate the failure reason. Currently 2225 defined failure reasons include: 2227 o Packet with size reported less than 20 bytes 2229 o Packet with version is not IPv4 2231 o Packet with header length less than 5 words 2233 o Packet with total length field less than 20 bytes 2235 o Packet with invalid checksum 2237 o Packet with invalid source address 2239 o Packet with invalid destination address 2241 5.2.1.2. Components 2243 This LFB has only one struct component, the 2244 IPv4ValidatorStatisticsType, which defines a set of statistics for 2245 validation process, including the number of bad header packets, the 2246 number of bad total length packets, the number of bad TTL packets, 2247 and the number of bad checksum packets. 2249 5.2.1.3. Capabilities 2251 This LFB does not have a list of capabilities 2253 5.2.1.4. Events 2255 This LFB does not have any events specified. 2257 5.2.2. IPv6Validator 2259 The IPv6Validator LFB performs IPv6 packets validation according to 2260 [RFC2460]. 2262 5.2.2.1. Data Handling 2264 This LFB performs IPv6 validation according to [RFC2460]. Then the 2265 IPv6 packet will be output to the corresponding port regarding of the 2266 validation result, whether the packet is a unicast or a multicast 2267 one, an exception has occurred or the validation failed. 2269 This LFB always expects, as input, packets which have been indicated 2270 as IPv6 packets by an upstream LFB, like an EtherClassifier LFB. 2271 There is no specific metadata expected by the input of the LFB. 2273 Similar to the IPv4validator LFB, IPv6Validator LFB has also defined 2274 four output ports to emit packets with various validation results. 2276 All validated IPv6 unicast packets will be output at the singleton 2277 port known as "IPv6UnicastOut". All validated IPv6 multicast packets 2278 will be output at the singleton port known as "IPv6MulticastOut" 2279 port. There is no metadata produced at this LFB. 2281 A singleton port known as "ExceptionOut" is defined to output packets 2282 which have been validated as exception packets. An exception case is 2283 the case when a packet needs further processing before being normally 2284 forwarded. An exception ID metadata is produced to indicate what 2285 caused the exception. Currently defined exception types include: 2287 o Packet with hop limit to zero 2289 o Packet with next header set to Hop-by-Hop 2291 o Packet with exceptional source address 2293 o Packet with exceptional destination address 2295 The final singleton port known as "FailOut" is defined for all 2296 packets which have errors and failed the validation process. An 2297 error case is the case when a packet is unable to be further 2298 processed nor forwarded except being dropped. A validate error ID is 2299 associated to every failed packet to indicate the reason. Currently 2300 defined reasons include: 2302 o Packet with size reported less than 40 bytes 2304 o Packet with not IPv6 version 2306 o Packet with invalid source address 2308 o Packet with invalid destination address 2310 Note that in the base type library, definitions for exception ID and 2311 validate error ID metadata are applied to both IPv4Validator and 2312 IPv6Validator LFBs, i.e., the two LFBs share the same medadata 2313 definition, with different ID assignment inside. 2315 5.2.2.2. Components 2317 This LFB has only one struct component, the 2318 IPv6ValidatorStatisticsType, which defines a set of statistics for 2319 validation process, including the number of bad header packets, the 2320 number of bad total length packets, and the number of bad hop limit 2321 packets. 2323 5.2.2.3. Capabilities 2325 This LFB does not have a list of capabilities 2327 5.2.2.4. Events 2329 This LFB does not have any events specified. 2331 5.3. IP Forwarding LFBs 2333 IP Forwarding LFBs are specifically defined to abstract the IP 2334 forwarding processes. As definitions for a base LFB library, this 2335 document restricts its LFB definition scope only to IP unicast 2336 forwarding. IP multicast may be defined in future documents. 2338 A typical IP unicast forwarding job is usually realized by looking up 2339 the forwarding information table to find next hop information, and 2340 then based on the next hop information, forwarding packets to 2341 specific physical output ports. It usually takes two steps to do so, 2342 firstly to look up a forwarding information table by means of Longest 2343 Prefix Matching(LPM) rule to find a next hop index, then to use the 2344 index as a search key to look up a next hop information table to find 2345 enough information to submit packets to output ports. This document 2346 abstracts the forwarding processes mainly based on the two steps 2347 model. However, there actually exists other models, like one which 2348 may only have a forwarding information base that have conjoined next 2349 hop information together with forwarding information. In this case, 2350 if ForCES technology is to be applied, some translation work will 2351 have to be done in the FE to translate attributes defined by this 2352 document into attributes related to the implementation. 2354 Based on the IP forwarding abstraction, two kind of typical IP 2355 unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next 2356 hop application LFB. They are further distinguished by IPv4 and IPv6 2357 protocols. 2359 5.3.1. IPv4UcastLPM 2361 The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match 2362 (LPM) process. 2364 This LFB also provides facilities to support users to implement 2365 equal-cost multi-path routing (ECMP) or reverse path forwarding 2366 (RPF). However, this LFB itself does not provide ECMP or RPF. To 2367 fully implement ECMP or RPF, additional specific LFBs, like a 2368 specific ECMP LFB or an RPF LFB, will have to be defined. This work 2369 may be done in the future version of the document. 2371 5.3.1.1. Data Handling 2373 This LFB performs the IPv4 unicast LPM table looking up. It always 2374 expects as input IPv4 unicast packets from one singleton input known 2375 as "PktsIn". Then the LFB uses the destination IPv4 address of every 2376 packet as search key to look up the IPv4 prefix table and generate a 2377 hop selector as the matching result. The hop selector is passed as 2378 packet metadata to downstream LFBs, and will usually be used there as 2379 a search index to find more next hop information. 2381 Three singleton output LFB ports are defined. 2383 The first singleton output known as "NormalOut" outputs IPv4 unicast 2384 packets that succeed the LPM lookup and (got a hop selector). The 2385 hop selector is associated with the packet as a metadata. Downstream 2386 from the LPM LFB is usually a next hop application LFB, like an 2387 IPv4NextHop LFB. 2389 The second singleton output known as "ECMPOut" is defined to provide 2390 support for users wishing to implement ECMP. 2392 An ECMP flag is defined in the LPM table to enable the LFB to support 2393 ECMP. When a table entry is created with the flag set true, it 2394 indicates this table entry is for ECMP only. A packet, which has 2395 passed through this prefix lookup, will always output from "ECMPOut" 2396 output port, with the hop selector being its lookup result. The 2397 output will usually directly go to a downstream ECMP processing LFB, 2398 where the hop selector can usually further generate optimized one or 2399 multiple next hop routes by use of ECMP algorithms. 2401 A default route flag is defined in the LPM table to enable the LFB to 2402 support a default route as well as loose RPF. When this flag is set 2403 true, the table entry is identified a default route which also 2404 implies that the route is forbidden for RPF. If a user wants to 2405 implement RPF on FE, a specific RPF LFB will have to be defined. In 2406 such RPF LFB, a component can be defined as an alias of the prefix 2407 table component of this LFB as described below. 2409 The final singleton output is known as "ExceptionOut" and is defined 2410 to allow exception packets to output here, along with an ExceptionID 2411 metadata to indicate what caused the exception. Currently defined 2412 exception types include: 2414 o The packet failed the LPM lookup of the prefix table. 2416 The upstream LFB of this LFB is usually IPv4Validator LFB. If RPF is 2417 to be adopted, the upstream can be an RPF LFB, when defined. 2419 The downstream LFB is usually IPv4NextHop LFB. If ECMP is adopted, 2420 the downstream can be an ECMP LFB, when defined. 2422 5.3.1.2. Components 2424 This LFB has two components. 2426 The IPv4PrefixTable component is defined as an array component of the 2427 LFB. Each row of the array contains an IPv4 address, a Prefix 2428 length, a Hop Selector, an ECMP flag and a Default Route flag. The 2429 LFB uses the destination IPv4 address of every input packet as search 2430 key to look up this table in order extract a next hop selector. The 2431 ECMP flag is for the LFB to support ECMP. The default route flag is 2432 for the LFB to support a default route and for loose RPF. 2434 The IPv4UcastLPMStats component is a struct component which collects 2435 statistics information, including the total number of input packets 2436 received, the IPv4 packets forwarded by this LFB and the number of IP 2437 datagrams discarded due to no route found. 2439 5.3.1.3. Capabilities 2441 This LFB does not have a list of capabilities 2443 5.3.1.4. Events 2445 This LFB does not have any events specified. 2447 5.3.2. IPv4NextHop 2449 This LFB abstracts the process of selecting ipv4 next hop action. 2451 5.3.2.1. Data Handling 2453 The LFB abstracts the process of next hop information application to 2454 IPv4 packets. It receives an IPv4 packet with an associated next hop 2455 identifier (HopSelector), and uses the identifier as a table index to 2456 look up a next hop table to find an appropriate LFB output port. 2458 The LFB is expected to receive unicast IPv4 packets, via a singleton 2459 input known as "PcktsIn" along with a HopSelector metadata which is 2460 used as a table index to lookup the NextHop table. The data 2461 processing involves the forwarding TTL decrement and IP checksum 2462 recalculation. 2464 Two output LFB ports are defined. 2466 The first output is a group output port known as "SuccessOut". On 2467 successful data processing the packet is sent out an LFB-port from 2468 within the LFB port group as selected by the LFBOutputSelectIndex 2469 value of the matched table entry. The packet is sent to a downstream 2470 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. 2472 The second output is a singleton output port known as "ExceptionOut", 2473 which will output packets for which the data processing failed, along 2474 with an additional ExceptionID metadata to indicate what caused the 2475 exception. Currently defined exception types include: 2477 o The HopSelector for the packet is invalid. 2479 o The packet failed lookup of the NextHop table even though the 2480 HopSelector is valid. 2482 o The MTU for outgoing interface is less than the packet size. 2484 Downstream LFB instances could be either a BasicMetadataDispatch type 2485 (Section 5.5.1), used to fanout to different LFB instances or a media 2486 encapsulation related type, such as an EtherEncap type or a 2487 RedirectOut type(Section 5.4.2). For example, if there are Ethernet 2488 and other tunnel Encapsulation, then a BasicMetadataDispatch LFB can 2489 use the L3PortID metadata (Section 5.3.2.2) to dispatch packets to 2490 different Encapsulator. 2492 5.3.2.2. Components 2494 This LFB has only one component named IPv4NextHopTable which is 2495 defined as an array. The HopSelector received is used to match the 2496 array index of IPv4NextHopTable to find out a row of the table as the 2497 next hop information result. Each row of the array is a struct 2498 containing: 2500 o The L3PortID, which is the ID of the Logical Output Port that is 2501 passed onto the downstream LFB instance. This ID indicates what 2502 port to the neighbor is as defined by L3. Usually this ID is used 2503 for the NextHop LFB to distinguish packets that need different L2 2504 encapsulating. For instance, some packets may require general 2505 Ethernet encapsulation while others may require various types of 2506 tunnel encapsulations. In such case, different L3PortIDs are 2507 assigned to the packets and are as metadata passed to downstream 2508 LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be 2509 applied as the downstream LFB so as to dispatch packets to 2510 different encapsulation LFB insatnces according to the L3PortIDs. 2512 o MTU, the Maximum Transmission Unit for the outgoing port. 2514 o NextHopIPAddr, the IPv4 next hop Address. 2516 o MediaEncapInfoIndex, the index we pass onto the downstream 2517 encapsulation LFB instance and that is used there as a search key 2518 to lookup a table (typically media encapsulation related) for 2519 further encapsulation information. Note that an encapsulation LFB 2520 instance may not directly follow the NextHop LFB, but the index is 2521 passed as a metadata associated, as such an encapsulation LFB 2522 instance even further downstream to the NextHop LFB can still use 2523 the index. In some cases, depending on implementation, the CE may 2524 set the MediaEncapInfoIndex passed downstream to a value that will 2525 fail lookup when it gets to a target encapsulation LFB; such a 2526 lookup failure at that point is an indication that further 2527 resolution is needed. For an example of this approach refer to 2528 Section 7.2 which talks about ARP and mentions this approach. 2530 o LFBOutputSelectIndex, the LFB Group output port index to select 2531 downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's 2532 table LFBTopology (See [RFC5812]) component FromPortIndex 2533 corresponding to the port group mapping FromLFBID as IPv4NextHop 2534 LFB instance. 2536 5.3.2.3. Capabilities 2538 This LFB does not have a list of capabilities 2540 5.3.2.4. Events 2542 This LFB does not have any events specified. 2544 5.3.3. IPv6UcastLPM 2546 The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match 2547 (LPM) process. The definition of this LFB is similar to the 2548 IPv4UcastLPM LFB except that all IP addresses refer to IPv6 2549 addresses. 2551 This LFB also provides facilities to support users to implement 2552 equal-cost multi-path routing (ECMP) or reverse path forwarding 2553 (RPF). However, this LFB itself does not provide ECMP or RPF. To 2554 fully implement ECMP or RPF, additional specific LFBs, like a 2555 specific ECMP LFB or an RPF LFB, will have to be defined. This work 2556 may be done in the future version of the document. 2558 5.3.3.1. Data Handling 2560 This LFB performs the IPv6 unicast LPM table look up. It always 2561 expects as input IPv6 unicast packets from one singleton input known 2562 as "PktsIn". The destination IPv6 address of an incoming packet is 2563 used as search key to look up the IPv6 prefix table and generate a 2564 hop selector. This hop selector result is associated to the packet 2565 as a metadata and sent to downstream LFBs, and will usually be used 2566 in downstream LFBs as a search key to find more next hop information. 2568 Three singleton output LFB ports are defined. 2570 The first singleton output known as "NormalOut" outputs IPv6 unicast 2571 packets that succeed the LPM lookup (and got a hop selector). The 2572 hop selector is associated with the packet as a metadata. Downstream 2573 from the LPM LFB is usually a next hop application LFB, like an 2574 IPv6NextHop LFB. 2576 The second singleton output known as "ECMPOut" is defined to provide 2577 support for users wishing to implement ECMP. 2579 An ECMP flag is defined in the LPM table to enable the LFB to support 2580 ECMP. When a table entry is created with the flag set true, it 2581 indicates this table entry is for ECMP only. A packet, which has 2582 passed through this prefix lookup, will always output from "ECMPOut" 2583 output port, with the hop selector being its lookup result. The 2584 output will usually directly go to a downstream ECMP processing LFB, 2585 where the hop selector can usually further generate optimized one or 2586 multiple next hop routes by use of ECMP algorithms. 2588 A default route flag is defined in the LPM table to enable the LFB to 2589 support a default route as well as loose RPF. When this flag is set 2590 true, the table entry is identified a default route which also 2591 implies that the route is forbidden for RPF. 2593 If a user wants to implement RPF on FE, a specific RPF LFB will have 2594 to be defined. In such RPF LFB, a component can be defined as an 2595 alias of the prefix table component of this LFB as described below. 2597 The final singleton output is known as "ExceptionOut" and is defined 2598 to allow exception packets to output here, along with an ExceptionID 2599 metadata to indicate what caused the exception. Currently defined 2600 exception types include: 2602 o The packet failed the LPM lookup of the prefix table. 2604 The upstream LFB of this LFB is usually IPv6Validator LFB. If RPF is 2605 to be adopted, the upstream can be an RPF LFB, when defined. 2607 The downstream LFB is usually an IPv6NextHop LFB. If ECMP is 2608 adopted, the downstream can be an ECMP LFB, when defined. 2610 5.3.3.2. Components 2612 This LFB has two components. 2614 The IPv6PrefixTable component is defined as an array component of the 2615 LFB. Each row of the array contains an IPv6 address, a Prefix 2616 length, a Hop Selector, an ECMP flag and a Default Route flag. The 2617 ECMP flag is so the LFB can support ECMP. The default route flag is 2618 for the LFB to support a default route and for loose RPF as described 2619 earlier. 2621 The IPv6UcastLPMStats component is a struct component which collects 2622 statistics information, including the total number of input packets 2623 received, the IPv6 packets forwarded by this LFB and the number of IP 2624 datagrams discarded due to no route found. 2626 5.3.3.3. Capabilities 2628 This LFB does not have a list of capabilities 2630 5.3.3.4. Events 2632 This LFB does not have any events specified. 2634 5.3.4. IPv6NextHop 2636 This LFB abstracts the process of selecting IPv6 next hop action. 2638 5.3.4.1. Data Handling 2640 The LFB abstracts the process of next hop information application to 2641 IPv6 packets. It receives an IPv6 packet with an associated next hop 2642 identifier (HopSelector), and uses the identifier to look up a next 2643 hop table to find an appropriate output port from the LFB. 2645 The LFB is expected to receive unicast IPv6 packets, via a singleton 2646 input known as "PcktsIn" along with a HopSelector metadata which is 2647 used as a table index to lookup the NextHop table. 2649 Two output LFB ports are defined. 2651 The first output is a group output port known as "SuccessOut". On 2652 successful data processing the packet is sent out an LFB port from 2653 within the LFB port group as selected by the LFBOutputSelectIndex 2654 value of the matched table entry. The packet is sent to a downstream 2655 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. 2657 The second output is a singleton output port known as "ExceptionOut", 2658 which will output packets for which the data processing failed, along 2659 with an additional ExceptionID metadata to indicate what caused the 2660 exception. Currently defined exception types include: 2662 o The HopSelector for the packet is invalid. 2664 o The packet failed lookup of the NextHop table even though the 2665 HopSelector is valid. 2667 o The MTU for outgoing interface is less than the packet size. 2669 Downstream LFB instances could be either a BasicMetadataDispatch 2670 type, used to fanout to different LFB instances or a media 2671 encapsulatation related type, such as an EtherEncap type or a 2672 RedirectOut type. For example, when the downstream LFB is 2673 BasicMetadataDispatch, and there exist Ethernet and other tunnel 2674 Encapsulation downstream from BasicMetadataDispatch, then the 2675 BasicMetadataDispatch LFB can use the L3PortID metadata (See section 2676 below) to dispatch packets to the different Encapsulator LFBs. 2678 5.3.4.2. Components 2680 This LFB has only one component named IPv6NextHopTable which is 2681 defined as an array. The array index of IPv6NextHopTable is used for 2682 a HopSelector to find out a row of the table as the next hop 2683 information. Each row of the array is a struct containing: 2685 o The L3PortID, which is the ID of the Logical Output Port that is 2686 passed onto the downstream LFB instance. This ID indicates what 2687 port to the neighbor is as defined by L3. Usually this ID is used 2688 for the NextHop LFB to distinguish packets that need different L2 2689 encapsulating. For instance, some packets may require general 2690 Ethernet encapsulation while others may require various types of 2691 tunnel encapsulations. In such case, different L3PortIDs are 2692 assigned to the packets and are as metadata passed to downstream 2693 LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be 2694 applied as the downstream LFB so as to dispatch packets to 2695 different encapsulation LFB instances according to the L3PortIDs. 2697 o MTU, the Maximum Transmission Unit for the outgoing port. 2699 o NextHopIPAddr, the IPv6 next hop Address. 2701 o MediaEncapInfoIndex, the index we pass onto the downstream 2702 encapsulation LFB instance and that is used there as a search key 2703 to lookup a table (typically media encapsulation related) for 2704 further encapsulation information. Note that an encapsulation LFB 2705 instance may not directly follow the NextHop LFB, but the index is 2706 passed as a metadata associated, as such an encapsulation LFB 2707 instance even further downstream to the NextHop LFB can still use 2708 the index. In some cases, depending on implementation, the CE may 2709 set the MediaEncapInfoIndex passed downstream to a value that will 2710 fail lookup when it gets to a target encapsulation LFB; such a 2711 lookup failure at that point is an indication that further 2712 resolution is needed. For an example of this approach refer to 2713 Section 7.2 which talks about ARP and mentions this approach. 2715 o LFBOutputSelectIndex, the LFB Group output port index to select 2716 downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's 2717 table LFBTopology (See [RFC5812]) component FromPortIndex 2718 corresponding to the port group mapping FromLFBID as IPv4NextHop 2719 LFB instance. 2721 5.3.4.3. Capabilities 2723 This LFB does not have a list of capabilities 2725 5.3.4.4. Events 2727 This LFB does not have any events specified. 2729 5.4. Redirect LFBs 2731 Redirect LFBs abstract data packets transportation process between CE 2732 and FE. Some packets output from some LFBs may have to be delivered 2733 to CE for further processing, and some packets generated by CE may 2734 have to be delivered to FE and further to some specific LFBs for data 2735 path processing. According to [RFC5810], data packets and their 2736 associated metadata are encapsulated in ForCES redirect message for 2737 transportation between CE and FE. We define two LFBs to abstract the 2738 process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an LFB 2739 topology of an FE, only one RedirectIn LFB instance and one 2740 RedirectOut LFB instance exist. 2742 5.4.1. RedirectIn 2744 RedirectIn LFB abstracts the process for the CE to inject data 2745 packets into the FE data path. 2747 5.4.1.1. Data Handling 2749 A RedirectIn LFB abstracts the process for the CE to inject data 2750 packets into the FE LFB topology so as to input data packets into FE 2751 data paths. From LFB topology point of view, the RedirectIn LFB acts 2752 as a source point for data packets coming from CE, therefore 2753 RedirectIn LFB is defined with a single output LFB port (and no input 2754 LFB port). 2756 The single output port of RedirectIn LFB is defined as a group output 2757 type, with the name of "PktsOut". Packets produced by this output 2758 will have arbitrary frame types decided by the CE which generated the 2759 packets. Possible frames may include IPv4, IPv6, or ARP protocol 2760 packets. The CE may associate some metadata to indicate the frame 2761 types and may also associate other metadata to indicate various 2762 information on the packets. Among them, there MUST exist a 2763 'RedirectIndex' metadata, which is an integer acting as an index. 2764 When the CE transmits the metadata along with the packet to a 2765 RedirectIn LFB, the LFB will read the RedirectIndex metadata and 2766 output the packet to one of its group output port instance, whose 2767 port index is indicated by this metadata. Any other metadata, in 2768 addition to 'RedirectIndex', will be passed untouched along the 2769 packet delivered by the CE to downstream LFB. This means the 2770 'RedirectIndex' metadata from CE will be "consumed" by the RedirectIn 2771 LFB and will not be passed to downstream LFB. Note that, a packet 2772 from CE without a 'RedirectIndex' metadata associated will be dropped 2773 by the LFB. 2775 5.4.1.2. Components 2777 There are no components defined for the current version of RedirectIn 2778 LFB. 2780 5.4.1.3. Capabilities 2782 This LFB does not have a list of capabilities 2784 5.4.1.4. Events 2786 This LFB does not have any events specified. 2788 5.4.2. RedirectOut 2790 RedirectOut LFB abstracts the process for LFBs in the FE to deliver 2791 data packets to the CE. 2793 5.4.2.1. Data Handling 2795 A RedirectOut LFB abstracts the process for LFBs in the FE to deliver 2796 data packets to the CE. From the LFB's topology point of view, the 2797 RedirectOut LFB acts as a sink point for data packets going to the 2798 CE, therefore RedirectOut LFB is defined with a single input LFB port 2799 (and no output LFB port). 2801 The RedirectOut LFB has only one singleton input known as "PktsIn", 2802 but is capable of receiving packets from multiple LFBs by 2803 multiplexing this input. The input expects any kind of frame type 2804 therefore the frame type has been specified as arbitrary, and also 2805 all types of metadata are expected. All associated metadata produced 2806 (but not consumed) by previous processed LFBs should be delivered to 2807 CE via the ForCES protocol redirect message [RFC5810]. The CE can 2808 decide on how to process the redirected packet by referencing the 2809 associated metadata. As an example, a packet could be redirected by 2810 the FE to the CE because the EtherEncap LFB is not able to resolve L2 2811 information. The metadata "ExceptionID", created by the EtherEncap 2812 LFB is passed along with the packet and should be sufficient for the 2813 CE to do the necessary processing and resolve the L2 entry required. 2815 5.4.2.2. Components 2817 There are no components defined for the current version of 2818 RedirectOut LFB. 2820 5.4.2.3. Capabilities 2822 This LFB does not have a list of capabilities 2824 5.4.2.4. Events 2826 This LFB does not have any events specified. 2828 5.5. General Purpose LFBs 2830 5.5.1. BasicMetadataDispatch 2832 The BasicMetadataDispatch LFB is defined to abstract the process in 2833 which a packet is dispatched to some output path based on its 2834 associated metadata value. 2836 5.5.1.1. Data Handling 2838 The BasicMetadataDispatch has only one singleton input known as 2839 "PktsIn". Every input packet should be associated with a metadata 2840 that will be used by the LFB to do the dispatch. This LFB contains a 2841 Metadata ID component a dispatch table named MetadataDispatchTable, 2842 all configured by the CE. The Metadata ID specifies which metadata 2843 is to be used for dispatching packets. The MetadataDispatchTable 2844 contains entries of a Metadata value and an OutputIndex, specifying 2845 that the packet with the metadata value must go out from the LFB 2846 group output port instance with the OutputIndex. 2848 Two output LFB ports are defined. 2850 The first output is a group output port known as "PktsOut". A packet 2851 with its associated metadata having found an OutputIndex by 2852 successfully looking up the dispatch table will be output to the 2853 group port instance with the corresponding index. 2855 The second output is a singleton output port known as "ExceptionOut", 2856 which will output packets for which the data processing failed, along 2857 with an additional ExceptionID metadata to indicate what caused the 2858 exception. Currently defined exception types include: 2860 o There is no matching when looking up the metadata dispatch table. 2862 As an example, if the CE decides to dispatch packets according to a 2863 physical port ID (PHYPortID), the CE may set the ID of PHYPortID 2864 metadata to the LFB first. Moreover, the CE also sets the PHYPortID 2865 actual values (the metadata values) and assigned OutputIndex for the 2866 values to the dispatch table in the LFB. When a packet arrives, a 2867 PHYPortID metadata is found associated with the packet, the metadata 2868 value is further used as a key to look up the dispatch table to find 2869 out an output port instance for the packet. 2871 Currently the BasicMetadataDispatch LFB only allows the metadata 2872 value of the dispatch table entry be 32-bits integer. A metadata 2873 with other types of value is not supported in this version. A more 2874 complex metadata dispatch LFB may be defined in future version of the 2875 library. In that LFB, multiple tuples of metadata with more value 2876 types supported may be used to dispatch packets. 2878 5.5.1.2. Components 2880 This LFB has two components. One component is MetadataID and the 2881 other is MetadataDispatchTable. Each row entry of the dispatch table 2882 is a struct containing metadata value and the OutputIndex. Note that 2883 currently, the metadata value is only allowed to be 32-bits integer. 2884 The metadata value is also defined as a content key for the table. 2885 The concept of content key is a searching key for tables which is 2886 defined in the ForCES FE Model [RFC5812]. See this document and also 2887 the ForCES Protocol [RFC5810] for more details on the definition and 2888 use of a content key. 2890 5.5.1.3. Capabilities 2892 This LFB does not have a list of capabilities 2894 5.5.1.4. Events 2896 This LFB does not have any events specified. 2898 5.5.2. GenericScheduler 2900 This is a preliminary generic scheduler LFB for abstracting a simple 2901 scheduling process. 2903 5.5.2.1. Data Handling 2905 There exist various kinds of scheduling strategies with various 2906 implementations. As a base LFB library, this document only defines a 2907 preliminary generic scheduler LFB for abstracting a simple scheduling 2908 process. Users may use this LFB as a basic scheduler LFB to further 2909 construct more complex scheduler LFBs by means of inheritance as 2910 described in [RFC5812]. 2912 Packets of any arbitrary frame type are received via a group input 2913 known as "PktsIn" with no additional metadata expected. This group 2914 input is capable of multiple input port instances. Each port 2915 instance may be connected to different upstream LFB output. 2917 Multiple queues reside at the input side, with every input LFB port 2918 instance connected to one queue. Every queue is marked with a queue 2919 ID, and the queue ID is exactly the same as the index of 2920 corresponding input port instance. Scheduling disciplines are 2921 applied to all queues and also all packets in the queues. 2923 Scheduled packets are output from a singleton output port of the LFB 2924 knows as "PktsOut" with no corresponding metadata. 2926 More complex scheduler LFBs may be defined with more complex 2927 scheduling disciplines by succeeding this LFB. For instance, a 2928 priority scheduler LFB may be defined by inheriting this LFB and 2929 defining a component to indicate priorities for all input queues. 2931 5.5.2.2. Components 2933 The QueueCount component is defined to specify the number of queues 2934 to be scheduled. 2936 The SchedulingDiscipline component is for the CE to specify a 2937 scheduling discipline to the LFB. Currently defined scheduling 2938 disciplines only include Round Robin (RR) strategy. The default 2939 scheduling discipline is RR then. 2941 The QueueStats component is defined to allow CE to query every queue 2942 status of the scheduler. It is an array component and each row of 2943 the array is a struct containing a queue ID. Currently defined queue 2944 status includes the queue depth in packets and the queue depth in 2945 bytes. Using the queue ID as the index, the CE can query every queue 2946 for its used length in unit of packets or bytes. 2948 5.5.2.3. Capabilities 2950 The following capability is currently defined for the 2951 GenericScheduler. 2953 o The queue length limit providing the storage ability for every 2954 queue. 2956 5.5.2.4. Events 2958 This LFB does not have any events specified. 2960 6. XML for LFB Library 2962 2963 2966 2967 2968 2969 EtherPHYCop 2970 The LFB describes an Ethernet port abstracted at 2971 physical layer.It limits its physical media to copper. 2972 Multiple virtual PHYs isn't supported in this LFB version. 2973 2974 1.0 2975 2976 2977 EtherPHYIn 2978 The input port of the EtherPHYCop LFB. It 2979 expects any kind of Ethernet frame. 2980 2981 2982 EthernetAll 2983 2984 2985 2986 2987 2988 2989 EtherPHYOut 2990 The output port of the EtherPHYCop LFB. It 2991 can produce any kind of Ethernet frame and along with 2992 the frame passes the ID of the Physical Port as 2993 metadata to be used by the next LFBs. 2994 2995 2996 EthernetAll 2997 2998 2999 PHYPortID 3000 3001 3002 3003 3004 3005 3006 PHYPortID 3007 The ID of the physical port that this LFB 3008 handles. 3009 uint32 3010 3011 3012 AdminStatus 3013 Admin status of the LFB 3014 PortStatusValues 3015 2 3016 3017 3018 OperStatus 3019 Operational status of the LFB. 3020 PortStatusValues 3021 3022 3023 AdminLinkSpeed 3024 The link speed that the admin has requested. 3025 3026 LANSpeedType 3027 LAN_SPEED_AUTO 3028 3029 3030 OperLinkSpeed 3031 The actual operational link speed. 3032 LANSpeedType 3033 3034 3035 AdminDuplexMode 3036 The duplex mode that the admin has requested. 3037 3038 DuplexType 3039 Auto 3040 3041 3042 OperDuplexMode 3043 The actual duplex mode. 3044 DuplexType 3045 3046 3047 CarrierStatus 3048 The status of the Carrier. Whether the port 3049 is linked with an operational connector. 3050 boolean 3051 false 3052 3053 3054 3055 3056 SupportedLinkSpeed 3057 Supported Link Speeds 3058 3059 LANSpeedType 3060 3061 3062 3063 SupportedDuplexMode 3064 Supported Duplex Modes 3065 3066 DuplexType 3067 3068 3069 3070 3071 3072 PHYPortStatusChanged 3073 When the status of the Physical port is 3074 changed,the LFB sends the new status. 3075 3076 OperStatus 3077 3078 3079 3080 3081 OperStatus 3082 3083 3084 3085 3086 LinkSpeedChanged 3087 When the operational speed of the link 3088 is changed, the LFB sends the new operational link 3089 speed. 3090 3091 OperLinkSpeed 3092 3093 3094 3095 3096 OperLinkSpeed 3097 3098 3099 3100 3101 DuplexModeChanged 3102 When the operational duplex mode 3103 is changed, the LFB sends the new operational mode. 3104 3105 3106 OperDuplexMode 3107 3108 3109 3110 3111 OperDuplexMode 3112 3113 3114 3115 3116 3117 3118 EtherMACIn 3119 An LFB abstracts an Ethernet port at MAC data link 3120 layer. It specifically describes Ethernet processing functions 3121 like MAC address locality check, deciding if the Ethernet 3122 packets should be bridged, provide Ethernet layer flow control, 3123 etc.Multiple virtual MACs isn't supported in this LFB 3124 version. 3125 1.0 3126 3127 3128 EtherPktsIn 3129 The input port of the EtherMACIn. It 3130 expects any kind of Ethernet frame. 3131 3132 3133 EthernetAll 3134 3135 3136 PHYPortID 3137 3138 3139 3140 3141 3142 3143 NormalPathOut 3144 The normal output port of the EtherMACIn. 3145 It can produce any kind of Ethernet frame and along 3146 with the frame passes the ID of the Physical Port as 3147 metadata to be used by the next LFBs. 3148 3149 3150 EthernetAll 3152 3153 3154 PHYPortID 3155 3156 3157 3158 3159 L2BridgingPathOut 3160 The Bridging Output Port of the EtherMACIn. 3161 It can produce any kind of Ethernet frame and along 3162 with the frame passes the ID of the Physical Port as 3163 metadata to be used by the next LFBs. 3164 3165 3166 EthernetAll 3167 3168 3169 PHYPortID 3170 3171 3172 3173 3174 3175 3176 AdminStatus 3177 Admin status of the port 3178 PortStatusValues 3179 2 3180 3181 3182 LocalMACAddresses 3183 Local Mac addresses 3184 3185 IEEEMAC 3186 3187 3188 3189 L2BridgingPathEnable 3190 Is the LFB doing L2 Bridging? 3191 boolean 3192 false 3193 3194 3195 PromiscuousMode 3196 Is the LFB in Promiscuous Mode? 3197 boolean 3198 false 3199 3200 3201 TxFlowControl 3202 Transmit flow control 3203 boolean 3204 false 3205 3206 3207 RxFlowControl 3208 Receive flow control 3209 boolean 3210 false 3211 3212 3213 MACInStats 3214 MACIn statistics 3215 MACInStatsType 3216 3217 3218 3219 3220 EtherClassifier 3221 This LFB abstracts the process to decapsulate 3222 Ethernet packets and classify the data packets into 3223 various network layer data packets according to information 3224 included in the Ethernet packets headers. 3225 1.0 3226 3227 3228 EtherPktsIn 3229 Input port for data packet. 3230 3231 3232 EthernetAll 3233 3234 3235 PHYPortID 3236 3237 LogicalPortID 3238 3239 3240 3241 3242 3243 3244 ClassifyOut 3245 Output port for classification. 3246 3247 3248 Arbitrary 3249 3250 3251 PHYPortID 3252 SrcMAC 3253 DstMAC 3254 EtherType 3255 VlanID 3256 VlanPriority 3257 3258 3259 3260 3261 3262 3263 EtherDispatchTable 3264 Ether classify dispatch table 3265 EtherDispatchTableType 3266 3267 3268 VlanInputTable 3269 Vlan input table 3270 VlanInputTableType 3271 3272 3273 EtherClassifyStats 3274 Ether classify statistic table 3275 EtherClassifyStatsTableType 3276 3277 3278 3279 3280 EtherEncap 3281 This LFB abstracts the process to encapsulate IP 3282 packets to Ethernet packets according to the L2 information. 3283 3284 1.0 3285 3286 3287 EncapIn 3288 A Single Packet Input 3289 3290 3291 IPv4 3292 IPv6 3293 3294 3295 MediaEncapInfoIndex 3296 3297 VlanPriority 3298 3299 3300 3301 3302 3303 3304 SuccessOut 3305 Output port for Packets which have found 3306 Ethernet L2 information and have been successfully 3307 encapsulated to an Ethernet packet. 3308 3309 3310 IPv4 3311 IPv6 3312 3313 3314 L2PortID 3315 3316 3317 3318 3319 ExceptionOut 3320 All packets that fail with the other 3321 operations in this LFB are output via this port. 3322 3323 3324 3325 IPv4 3326 IPv6 3327 3328 3329 ExceptionID 3330 MediaEncapInfoIndex 3331 VlanPriority 3332 3333 3334 3335 3336 3337 3338 EncapTable 3339 Ethernet Encapsulation table. 3340 EncapTableType 3341 3342 3343 3344 3345 EtherMACOut 3346 EtherMACOut LFB abstracts an Ethernet port at MAC 3347 data link layer. It specifically describes Ethernet packet 3348 output process. Ethernet output functions are closely related 3349 to Ethernet input functions, therefore some components 3350 defined in this LFB are actually alias of EtherMACIn LFB. 3351 3352 1.0 3353 3354 3355 EtherPktsIn 3356 The Input Port of the EtherMACIn. It expects 3357 any kind of Ethernet frame. 3358 3359 3360 EthernetAll 3361 3362 3363 PHYPortID 3364 3365 3366 3367 3368 3369 3370 EtherPktsOut 3371 The Normal Output Port of the EtherMACOut. It 3372 can produce any kind of Ethernet frame and along with 3373 the frame passes the ID of the Physical Port as 3374 metadata to be used by the next LFBs. 3375 3376 3377 EthernetAll 3378 3379 3380 PHYPortID 3381 3382 3383 3384 3385 3386 3387 AdminStatus 3388 Admin status of the port. It is the alias of 3389 "AdminStatus" component defined in EtherMACIn. 3390 3391 PortStatusValues 3393 3394 3395 MTU 3396 Maximum transmission unit. 3397 uint32 3398 3399 3400 TxFlowControl 3401 Transmit flow control. It is the alias of 3402 "TxFlowControl" component defined in EtherMACIn. 3403 3404 boolean 3405 3406 3407 RxFlowControl 3408 Receive flow control. It is the alias of 3409 "RxFlowControl" component defined in EtherMACIn. 3410 3411 boolean 3412 3413 3414 MACOutStats 3415 MACOut statistics 3416 MACOutStatsType 3417 3418 3419 3420 3421 IPv4Validator 3422 An LFB that performs IPv4 packets validation 3423 according to RFC1812. At the same time, ipv4 unicast and 3424 multicast are classified in this LFB. 3425 1.0 3426 3427 3428 ValidatePktsIn 3429 Input port for data packet. 3430 3431 3432 Arbitrary 3433 3434 3435 3436 3437 3438 3439 IPv4UnicastOut 3440 Output for IPv4 unicast packet. 3441 3442 3443 IPv4Unicast 3444 3445 3446 3447 3448 IPv4MulticastOut 3449 Output for IPv4 multicast packet. 3450 3451 3452 IPv4Multicast 3453 3454 3455 3456 3457 ExceptionOut 3458 Output for exception packet. 3459 3460 3461 IPv4 3462 3463 3464 ExceptionID 3465 3466 3467 3468 3469 FailOut 3470 Output for failed validation packet. 3471 3472 3473 3474 IPv4 3475 3476 3477 ValidateErrorID 3478 3479 3480 3481 3482 3483 3484 IPv4ValidatorStats 3485 IPv4 validator statistics information. 3486 3487 IPv4ValidatorStatsType 3488 3490 3491 3492 3493 IPv6Validator 3494 An LFB that performs IPv6 packets validation 3495 according to RFC2460. At the same time, ipv6 unicast and 3496 multicast are classified in this LFB. 3497 1.0 3498 3499 3500 ValidatePktsIn 3501 Input port for data packet. 3502 3503 3504 Arbitrary 3505 3506 3507 3508 3509 3510 3511 IPv6UnicastOut 3512 Output for IPv6 unicast packet. 3513 3514 3515 IPv6Unicast 3516 3517 3518 3519 3520 IPv6MulticastOut 3521 Output for IPv6 multicast packet. 3522 3523 3524 IPv6Multicast 3525 3526 3527 3528 3529 ExceptionOut 3530 Output for exception packet. 3531 3532 3533 IPv6 3534 3535 3536 ExceptionID 3537 3539 3540 3541 3542 FailOut 3543 Output for failed validation packet. 3544 3545 3546 3547 IPv6 3548 3549 3550 ValidateErrorID 3551 3552 3553 3554 3555 3556 3557 IPv6ValidatorStats 3558 IPv6 validator statistics information. 3559 3560 IPv6ValidatorStatsType 3561 3562 3563 3564 3565 IPv4UcastLPM 3566 An LFB that performs IPv4 Longest Prefix Match 3567 Lookup.It is defined to provide some facilities to support 3568 users to implement equal-cost multi-path routing(ECMP) or 3569 reverse path forwarding (RPF). 3570 1.0 3571 3572 3573 PktsIn 3574 A Single Packet Input 3575 3576 3577 IPv4Unicast 3578 3579 3580 3581 3582 3583 3584 NormalOut 3585 This output port is connected with 3586 IPv4NextHop LFB 3587 3588 3589 IPv4Unicast 3590 3591 3592 HopSelector 3593 3594 3595 3596 3597 ECMPOut 3598 This output port is connected with ECMP LFB, 3599 if there is ECMP LFB in the FE. 3600 3601 3602 IPv4Unicast 3603 3604 3605 HopSelector 3606 3607 3608 3609 3610 ExceptionOut 3611 The output for the packet if an exception 3612 occurs 3613 3614 3615 IPv4Unicast 3616 3617 3618 ExceptionID 3619 3620 3621 3622 3623 3624 3625 IPv4PrefixTable 3626 The IPv4 prefix table. 3627 IPv4PrefixTableType 3628 3629 3630 IPv4UcastLPMStats 3631 Statistics for IPv4 Unicast Longest Prefix 3632 Match 3633 IPv4UcastLPMStatsType 3634 3636 3637 3638 3639 IPv6UcastLPM 3640 An LFB that performs IPv6 Longest Prefix Match 3641 Lookup.It is defined to provide some facilities to support 3642 users to implement equal-cost multi-path routing(ECMP) or 3643 reverse path forwarding (RPF). 3644 1.0 3645 3646 3647 PktsIn 3648 A Single Packet Input 3649 3650 3651 IPv6Unicast 3652 3653 3654 3655 3656 3657 3658 NormalOut 3659 This output port is connected with 3660 IPv6NextHop LFB 3661 3662 3663 IPv6Unicast 3664 3665 3666 HopSelector 3667 3668 3669 3670 3671 ECMPOut 3672 This output port is connected with ECMP LFB, 3673 if there is ECMP LFB in the FE. 3674 3675 3676 IPv6Unicast 3677 3678 3679 HopSelector 3680 3681 3682 3683 3684 ExceptionOut 3685 The output for the packet if an exception 3686 occurs 3687 3688 3689 IPv6Unicast 3690 3691 3692 ExceptionID 3693 3694 3695 3696 3697 3698 3699 IPv6PrefixTable 3700 The IPv6 prefix table. 3701 IPv6PrefixTableType 3702 3703 3704 IPv6UcastLPMStats 3705 Statistics for IPv6 Unicast Longest Prefix 3706 Match 3707 IPv6UcastLPMStatsType 3708 3709 3710 3711 3712 IPv4NextHop 3713 This LFB abstracts the process of selecting ipv4 3714 next hop action. It receives an IPv4 packet with an 3715 associated next hop ID, and uses the ID to look up a next 3716 hop table to find an appropriate output port from the LFB. 3717 3718 1.0 3719 3720 3721 PktsIn 3722 A Single Packet Input 3723 3724 3725 IPv4Unicast 3726 3727 3728 HopSelector 3729 3730 3731 3733 3734 3735 3736 SuccessOut 3737 The output for the packet if it is valid to be 3738 forwarded 3739 3740 3741 IPv4Unicast 3742 3743 3744 L3PortID 3745 NextHopIPv4Addr 3746 3747 MediaEncapInfoIndex 3748 3749 3750 3751 3752 ExceptionOut 3753 The output for the packet if an exception 3754 occurs 3755 3756 3757 IPv4Unicast 3758 3759 3760 ExceptionID 3761 3762 3763 3764 3765 3766 3767 IPv4NextHopTable 3768 The next hop table. 3769 IPv4NextHopTableType 3770 3771 3772 3773 3774 IPv6NextHop 3775 The LFB abstracts the process of next hop 3776 information application to IPv6 packets. It receives an IPv4 3777 packet with an associated next hop ID, and uses the ID to 3778 look up a next hop table to find an appropriate output port 3779 from the LFB.. 3780 1.0 3781 3782 3783 PktsIn 3784 A single packet input. 3785 3786 3787 IPv6Unicast 3788 3789 3790 HopSelector 3791 3792 3793 3794 3795 3796 3797 SuccessOut 3798 The output for the packet if it is valid to 3799 be forwarded 3800 3801 3802 IPv6Unicast 3803 3804 3805 L3PortID 3806 NextHopIPv6Addr 3807 3808 MediaEncapInfoIndex 3809 3810 3811 3812 3813 ExceptionOut 3814 The output for the packet if an exception 3815 occurs 3816 3817 3818 IPv6Unicast 3819 3820 3821 ExceptionID 3822 3823 3824 3825 3826 3827 3828 IPv6NextHopTable 3829 The next hop table. 3830 IPv6NextHopTableType 3831 3832 3833 3834 3835 RedirectIn 3836 The RedirectIn LFB abstracts the process for CE to 3837 inject data packets into FE LFB topology, so as to input data 3838 packets into FE data paths. CE may associate some 3839 metadata to data packets to indicate various information on 3840 the packets. Among them, there MUST exist a 'RedirectIndex' 3841 metadata, which is an integer acting as an output port index. 3842 3843 1.0 3844 3845 3846 PktsOut 3847 This output group sends the redirected packet 3848 in the data path. 3849 3850 3851 Arbitrary 3852 3853 3854 3855 3856 3857 3858 RedirectOut 3859 The LFB abstracts the process for LFBs in 3860 FE to deliver data packets to CE. All metadata 3861 associated with the input packets will be delivered to CE 3862 via the redirect message of ForCES protocol [RFC5810]. 3863 3864 1.0 3865 3866 3867 PktsIn 3868 This input receives packets to send to 3869 the CE. 3870 3871 3872 Arbitrary 3873 3874 3875 3876 3878 3879 3880 BasicMetadataDispatch 3881 This LFB provides the function to dispatch input 3882 packets to a group output according to a metadata and a 3883 dispatch table.This LFB currently only allow a metadata with 3884 an interger value to be used for dispatch. 3885 1.0 3886 3887 3888 PktsIn 3889 Input port for data packet. 3890 3891 3892 Arbitrary 3893 3894 3895 Arbitrary 3896 3897 3898 3899 3900 3901 3902 PktsOut 3903 Data packet output 3904 3905 3906 Arbitrary 3907 3908 3909 3910 3911 3912 3913 MetadataID 3914 the metadata ID for dispatching 3915 uint32 3916 3917 3918 MetadataDispatchTable 3919 Metadata dispatch table. 3920 MetadataDispatchTableType 3921 3922 3923 3924 3925 GenericScheduler 3926 This is a preliminary generic scheduler LFB for 3927 abstracting a simple scheduling process.Users may use this 3928 LFB as a basic scheduler LFB to further construct more 3929 complex scheduler LFBs by means of inheritance as described 3930 in RFC5812. 3931 1.0 3932 3933 3934 PktsIn 3935 Input port for data packet. 3936 3937 3938 Arbitrary 3939 3940 3941 3942 3943 3944 3945 PktsOut 3946 Data packet output. 3947 3948 3949 Arbitrary 3950 3951 3952 3953 3954 3955 3956 QueueCount 3957 The number of queues to be scheduled. 3958 3959 uint32 3960 3961 3962 SchedulingDiscipline 3963 the Scheduler discipline. 3964 SchdDisciplineType 3965 3966 3967 QueueStats 3968 Current statistics for all queues 3969 QueueStatsTableType 3970 3971 3972 3973 3974 QueueLenLimit 3975 Maximum length of each queue,the unit is 3976 byte. 3977 uint32 3978 3979 3980 3981 3982 3983 7. LFB Class Use Cases 3985 This section demonstrates examples on how the LFB classes defined by 3986 the Base LFB library in Section 6 can be applied to achieve some 3987 typical router functions. The functions demonstrated are: 3989 o IPv4 forwarding 3991 o ARP processing 3993 It is assumed the LFB topology on the FE described has already been 3994 established by the CE and maps to the use cases illustrated in this 3995 section. 3997 The use cases demonstrated in this section are mere examples and by 3998 no means should be treated as the only way one would construct router 3999 functionality from LFBs; based on the capability of the FE(s), a CE 4000 should be able to express different NE applications. 4002 7.1. IPv4 Forwarding 4004 Figure 1 (Section 3.2.3) shows a typical IPv4 forwarding processing 4005 path by use of the base LFB classes. 4007 A number of EtherPHYCop LFB(Section 5.1.1) instances are used to 4008 describe physical layer functions of the ports. PHYPortID metadata 4009 is generated by EtherPHYCop LFB and is used by all the subsequent 4010 downstream LFBs. An EtherMACIn LFB(Section 5.1.2), which describe 4011 the MAC layer processing, follows every EtherPHYCop LFB. The 4012 EtherMACIn LFB may do a locality check of MAC addresses if the CE 4013 configures the appropriate EtherMACIn LFB component. 4015 Ethernet packets out of the EtherMACIn LFB are sent to an 4016 EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified 4017 into network layer types like IPv4, IPv6, ARP, etc. In the example 4018 use case, every physical Ethernet interface is associated with one 4019 Classifier instance; although not illustrated, it is also feasible 4020 that all physical interfaces are associated with only one Ethernet 4021 Classifier instance. 4023 EtherClassifier uses the PHYPortID metadata, the Ethernet type of the 4024 input packet, and VlanID (if present in the input Ethernet packets), 4025 to decide the packet network layer type and the LFB output port to 4026 the downstream LFB. The EtherClassifier LFB also assigns a new 4027 logical port ID metadata to the packet for later use. The 4028 EtherClassifier may also generate some new metadata for every packet 4029 like EtherType, SrcMAC, DstMAC, LogicPortID, etc for consumption by 4030 downstream LFBs. 4032 If a packet is classified as an IPv4 packet, it is sent downstream to 4033 an IPv4Validator LFB (Section 5.2.1) to validate the IPv4 packet. In 4034 the validator LFB, IPv4 packets are validated and are additionally 4035 classified into either IPv4 unicast packets or multicast packets. 4036 IPv4 unicast packets are sent to downstream to the IPv4UcastLPM LFB 4037 (Section 5.3.1). 4039 The IPv4UcastLPM LFB is where the longest prefix match decision is 4040 made, and a next hop selection is selected. The nexthop ID metadata 4041 is generated by the IPv4UcastLPM LFB to be consumed downstream by the 4042 IPv4NextHop LFB (Section 5.3.2). 4044 The IPv4NextHop LFB uses the nexthop ID metadata to do derive where 4045 the packet is to go next and the media encapsulation type for the 4046 port, etc. The IPv4NextHop LFB generates the L3PortID metadata used 4047 to identify a next hop output physical/logical port. In the example 4048 use case, the next hop output port is an Ethernet type; as a result, 4049 the packet and its L3 port ID metadata are sent downstream to an 4050 EtherEncap LFB (Section 5.1.4). 4052 The EtherEncap LFB encapsulates the incoming packet into an Ethernet 4053 frame. A BasicMetadataDispatch LFB (Section 5.5.1) follows the 4054 EtherEncap LFB. The BasicMetadataDispatch LFB is where packets are 4055 finally dispatched to different output physical/logical ports based 4056 on the L3PortID metadata sent to the LFB. 4058 7.2. ARP processing 4060 Figure 2 shows the processing path for ARP protocol in the case the 4061 CE implements the ARP processing function. By no means is this the 4062 only way ARP processing could be achieved; as an example ARP 4063 processing could happen at the FE - but that discussion is out of 4064 scope for this use case. 4066 +---+ +---+ 4067 | | ARP packets | | 4068 | |------------------------+--->| | To CE 4069 ...-->| | . | | | 4070 | | . | +---+ 4071 | | . | RedirectOut 4072 +---+ | 4073 Ether EtherEncap | IPv4 packets lack 4074 Classifier +---+ | address resolution information 4075 | | | 4076 Packets need | |--------->---+ 4077 ...--------->| | 4078 L2 Encapsulation| | 4079 +---+ | | +------+ 4080 | | +-->| |--+ +---+ |Ether | 4081 | | | +---+ | | |--------->|MACOut|-->... 4082 From CE| |--+ +-->| | . +------+ 4083 | |ARP Packets | | . 4084 | |from CE | | . +------+ 4085 | | | |--------> |Ether |-->... 4086 +---+ +---+ |MACOut| 4087 RedirectIn BasicMetadata +------+ 4088 Dispatch 4090 Figure 2: LFB use case for ARP 4092 There are two ways ARP processing could be triggered in the CE as 4093 illustrated in Figure 2: 4095 o ARP packets arriving from outside of the NE. 4097 o IPV4 packets failing to resolve within the FE. 4099 ARP packets from network interfaces are filtered out by 4100 EtherClassifier LFB. The classified ARP packets and associated 4101 metadata are then sent downstream to the RedirectOut LFB 4102 (Section 5.4.2) to be transported to CE. 4104 The EtherEncap LFB, as described earlier, receives packets that need 4105 Ethernet L2 encapsulating. When the EtherEncap LFB fails to find the 4106 necessary L2 Ethernet information to encapsulate the packet with, it 4107 outputs the packet to its ExceptionOut LFB port. Downstream to 4108 EtherEncap LFB's ExceptionOut LFB port is the RedirectOut LFB which 4109 transports the packet to the CE (Section 5.1.4 on EtherEncap LFB for 4110 details). 4112 To achieve its goal, the CE needs to generate ARP request and 4113 response packets and send them to external (to the NE) networks. ARP 4114 request and response packets from the CE are redirected to an FE via 4115 a RedirectIn LFB (Section 5.4.1). 4117 As was the case with forwarded IPv4 packets, outgoing ARP packets are 4118 also encapsulated to Ethernet format by the EtherEncap LFB, and then 4119 dispatched to different interfaces via a BasicMetadataDispatch LFB. 4120 The BasicMetadataDispatch LFB dispatches the packets according to the 4121 L3PortID metadata included in every ARP packet sent from CE. 4123 8. Contributors 4125 The authors would like to thank Jamal Hadi Salim, Ligang Dong, and 4126 Fenggen Jia who made major contributions to the development of this 4127 document. 4129 Jamal Hadi Salim 4130 Mojatatu Networks 4131 Ottawa, Ontario 4132 Canada 4133 Email: hadi@mojatatu.com 4135 Ligang Dong 4136 Zhejiang Gongshang University 4137 149 Jiaogong Road 4138 Hangzhou 310035 4139 P.R.China 4140 Phone: +86-571-28877751 4141 EMail: donglg@mail.zjgsu.edu.cn 4143 Fenggen Jia 4144 National Digital Switching Center(NDSC) 4145 Jianxue Road 4146 Zhengzhou 452000 4147 P.R.China 4148 EMail: jfg@mail.ndsc.com.cn 4150 9. Acknowledgements 4152 This document is based on earlier documents from Joel Halpern, Ligang 4153 Dong, Fenggen Jia and Weiming Wang. 4155 10. IANA Considerations 4157 IANA has created a registry of ForCES LFB Class Names and the 4158 corresponding ForCES LFB Class Identifiers, with the location of the 4159 definition of the ForCES LFB Class, in accordance with the rules to 4160 use the namespace. 4162 The LFB library in this document needs for unique class names and 4163 numeric class identifiers of all LFBs. Besides, this document also 4164 needs to define the following namespaces: 4166 o Metadata ID, defined in Section 4.3 and Section 4.4 4168 o Exception ID, defined in Section 4.4 4170 o Validate Error ID, defined in Section 4.4 4172 10.1. LFB Class Names and LFB Class Identifiers 4174 LFB classes defined by this document belongs to IETF defined LFBs by 4175 Standard Track RFCs. According to IANA, the identifier namespace for 4176 these LFB classes is from 3 to 65535. 4178 The assignment of LFB class names and LFB class identifiers is as in 4179 the following table. 4181 +-----------+---------------+------------------------+--------------+ 4182 | LFB Class | LFB Class Name| Description | Reference | 4183 | Identifier| | | | 4184 +-----------+---------------+------------------------+--------------+ 4185 | 3 | EtherPHYCop | Define an Ethernet port| RFC????(this| 4186 | | | abstracted at physical | document) | 4187 | | | layer | Section 5.1.1| 4188 | | | -------------- | | 4189 | 4 | EtherMACIn | Define an Ethernet | RFC???? | 4190 | | | input port at MAC data | Section 5.1.2| 4191 | | | link layer | | 4192 | | | -------------- | | 4193 | 5 |EtherClassifier| Define the process to | RFC???? | 4194 | | | decapsulate Ethernet | Section 5.1.3| 4195 | | | packets and classify | | 4196 | | | the packets | | 4197 | | | -------------- | | 4198 | 6 | EtherEncap | Define the process to | RFC???? | 4199 | | | encapsulate IP packets | Section 5.1.4| 4200 | | | to Ethernet packets | | 4201 | | | -------------- | | 4202 | 7 | EtherMACOut | Define an Ethernet | RFC ???? | 4203 | | | output port at MAC | Section 5.1.5| 4204 | | | data link layer | | 4205 | | | -------------- | | 4206 | 8 | IPv4Validator | Perform IPv4 packets | RFC ???? | 4207 | | | validation. | Section 5.2.1| 4208 | | | -------------- | | 4209 | 9 | IPv6Validator | Perform IPv6 packets | RFC ???? | 4210 | | | validation | Section 5.2.2| 4211 | | | -------------- | | 4212 | 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? | 4213 | | | Prefix Match Lookup | Section 5.3.1| 4214 | | | -------------- | | 4215 | 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC ???? | 4216 | | | Prefix Match Lookup | Section 5.3.3| 4217 | | | -------------- | | 4218 | 12 | IPv4NextHop | Define the process of | RFC ??? | 4219 | | | selecting Ipv4 next hop| Section 5.3.2| 4220 | | | action | | 4221 | | | -------------- | | 4222 | 13 | IPv6NextHop | Define the process of | RFC ??? | 4223 | | | selecting Ipv6 next hop| Section 5.3.4| 4224 | | | action | | 4225 | | | -------------- | | 4226 | 14 | RedirectIn | Define the process for | RFC ??? | 4227 | | | CE to inject data | Section 5.4.1| 4228 | | | packets into FE LFB | | 4229 | | | topology | | 4230 | | | -------------- | | 4231 | 15 | RedirectOut | Define the process for | RFC ??? | 4232 | | | LFBs in FE to deliver | Section 5.4.2| 4233 | | | data packets to CE | | 4234 | | | -------------- | | 4235 | 16 |BasicMetadata | Dispatch input packets | RFC ??? | 4236 | |Dispatch | to a group output | Section 5.5.1| 4237 | | | according to a metadata| | 4238 | | | -------------- | | 4239 | 17 |Generic | Define a preliminary | RFC ???? | 4240 | |Scheduler | generic scheduling | Section 5.5.2| 4241 | | | process | | 4242 +-----------+---------------+------------------------+--------------+ 4244 Table 1 4246 10.2. Metadata ID 4248 The Metadata ID namespace is 32 bits long. The following is the 4249 guideline for managing the namespace. 4251 Metadata ID 0x00000000-0x7FFFFFFF 4252 Metadata with IDs in this range are Specification Required 4253 [RFC5226]. A metadata ID using this range MUST be documented in 4254 an RFC or other permanent and readily available references. 4256 Values assigned by this specification: 4258 +--------------+-------------------------+--------------------------+ 4259 | Value | Name | Definition | 4260 +--------------+-------------------------+--------------------------+ 4261 | 0x00000001 | PHYPortID | See Section 4.4 | 4262 | 0x00000002 | SrcMAC | See Section 4.4 | 4263 | 0x00000003 | DstMAC | See Section 4.4 | 4264 | 0x00000004 | LogicalPortID | See Section 4.4 | 4265 | 0x00000005 | EtherType | See Section 4.4 | 4266 | 0x00000006 | VlanID | See Section 4.4 | 4267 | 0x00000007 | VlanPriority | See Section 4.4 | 4268 | 0x00000008 | NexthopIPv4Addr | See Section 4.4 | 4269 | 0x00000009 | NexthopIPv6Addr | See Section 4.4 | 4270 | 0x0000000A | HopSelector | See Section 4.4 | 4271 | 0x0000000B | ExceptionID | See Section 4.4 | 4272 | 0x0000000C | ValidateErrorID | See Section 4.4 | 4273 | 0x0000000D | L3PortID | See Section 4.4 | 4274 | 0x0000000E | RedirectIndex | See Section 4.4 | 4275 | 0x0000000F | MediaEncapInfoIndex | See Section 4.4 | 4276 +--------------+-------------------------+--------------------------+ 4278 Table 2 4280 Metadata ID 0x80000000-0xFFFFFFFF 4281 Metadata IDs in this range are reserved for vendor private 4282 extensions and are the responsibility of individuals. 4284 10.3. Exception ID 4286 The Exception ID namespace is 32 bits long. The following is the 4287 guideline for managing the namespace. 4289 Exception ID 0x00000000-0x7FFFFFFF 4290 Exception IDs in this range are Specification Required [RFC5226]. 4291 An exception ID using this range MUST be documented in an RFC or 4292 other permanent and readily available references. 4294 Values assigned by this specification: 4296 +--------------+---------------------------------+------------------+ 4297 | Value | Name | Definition | 4298 +--------------+---------------------------------+------------------+ 4299 | 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 | 4300 | 0x00000001 | ClassifyNoMatching | See Section 4.4 | 4301 | 0x00000002 | MediaEncapInfoIndexInvalid | See Section 4.4 | 4302 | 0x00000003 | EncapTableLookupFailed | See Section 4.4 | 4303 | 0x00000004 | BadTTL | See Section 4.4 | 4304 | 0x00000005 | IPv4HeaderLengthMismatch | See Section 4.4 | 4305 | 0x00000006 | RouterAlertOptions | See Section 4.4 | 4306 | 0x00000007 | IPv6HopLimitZero | See Section 4.4 | 4307 | 0x00000008 | IPv6NextHeaderHBH | See Section 4.4 | 4308 | 0x00000009 | SrcAddressExecption | See Section 4.4 | 4309 | 0x0000000A | DstAddressExecption | See Section 4.4 | 4310 | 0x0000000B | LPMLookupFailed | See Section 4.4 | 4311 | 0x0000000C | HopSelectorInvalid | See Section 4.4 | 4312 | 0x0000000D | NextHopLookupFailed | See Section 4.4 | 4313 | 0x0000000E | FragRequired | See Section 4.4 | 4314 | 0x0000000F | MetadataNoMatching | See Section 4.4 | 4315 +--------------+---------------------------------+------------------+ 4317 Table 3 4319 Exception ID 0x80000000-0xFFFFFFFF 4320 Exception IDs in this range are reserved for vendor private 4321 extensions and are the responsibility of individuals. 4323 10.4. Validate Error ID 4325 The Validate Error ID namespace is 32 bits long. The following is 4326 the guideline for managing the namespace. 4328 Validate Error ID 0x00000000-0x7FFFFFFF 4329 Validate Error IDs in this range are Specification Required 4330 [RFC5226]. A Validate Error ID using this range MUST be 4331 documented in an RFC or other permanent and readily available 4332 references. 4334 Values assigned by this specification: 4336 +--------------+---------------------------------+------------------+ 4337 | Value | Name | Definition | 4338 +--------------+---------------------------------+------------------+ 4339 | 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 | 4340 | 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 | 4341 | 0x00000002 | NotIPv4Packet | See Section 4.4 | 4342 | 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 | 4343 | 0x00000004 | InvalidIPv4LengthFieldSize | See Section 4.4 | 4344 | 0x00000005 | InvalidIPv4Checksum | See Section 4.4 | 4345 | 0x00000006 | InvalidIPv4SrcAddr | See Section 4.4 | 4346 | 0x00000007 | InvalidIPv4DstAddr | See Section 4.4 | 4347 | 0x00000008 | InvalidIPv6PakcetSize | See Section 4.4 | 4348 | 0x00000009 | NotIPv6Packet | See Section 4.4 | 4349 | 0x0000000A | InvalidIPv6SrcAddr | See Section 4.4 | 4350 | 0x0000000B | InvalidIPv6DstAddr | See Section 4.4 | 4351 +--------------+---------------------------------+------------------+ 4352 Table 4 4354 Validate Error ID 0x80000000-0xFFFFFFFF 4355 Validate Error IDs in this range are reserved for vendor private 4356 extensions and are the responsibility of individuals. 4358 11. Security Considerations 4360 The ForCES framework document [RFC3746] provides a comprehensive 4361 security analysis for the overall ForCES architecture. For example, 4362 the ForCES protocol entities must be authenticated per the ForCES 4363 requirements before they can access the information elements 4364 described in this document via ForCES. Access to the information 4365 contained in this document is accomplished via the ForCES 4366 protocol[RFC5810], which is defined in separate documents, and thus 4367 the security issues will be addressed there. 4369 12. References 4371 12.1. Normative References 4373 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 4374 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 4375 Control Element Separation (ForCES) Protocol 4376 Specification", RFC 5810, March 2010. 4378 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 4379 Element Separation (ForCES) Forwarding Element Model", 4380 RFC 5812, March 2010. 4382 12.2. Informative References 4384 [RFC1122] Braden, R., "Requirements for Internet Hosts - 4385 Communication Layers", STD 3, RFC 1122, October 1989. 4387 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 4388 RFC 1812, June 1995. 4390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4391 Requirement Levels", BCP 14, RFC 2119, March 1997. 4393 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4394 (IPv6) Specification", RFC 2460, December 1998. 4396 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 4397 June 1999. 4399 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 4400 Text on Security Considerations", BCP 72, RFC 3552, 4401 July 2003. 4403 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 4404 of IP Control and Forwarding", RFC 3654, November 2003. 4406 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 4407 "Forwarding and Control Element Separation (ForCES) 4408 Framework", RFC 3746, April 2004. 4410 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4411 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 4412 May 2008. 4414 Authors' Addresses 4416 Weiming Wang 4417 Zhejiang Gongshang University 4418 18 Xuezheng Str., Xiasha University Town 4419 Hangzhou, 310018 4420 P.R.China 4422 Phone: +86 571 28877721 4423 Email: wmwang@zjsu.edu.cn 4425 Evangelos Haleplidis 4426 University of Patras 4427 Patras, 4428 Greece 4430 Email: ehalep@ece.upatras.gr 4432 Kentaro Ogawa 4433 NTT Corporation 4434 Tokyo, 4435 Japan 4437 Email: ogawa.kentaro@lab.ntt.co.jp 4439 Chuanhuang Li 4440 Hangzhou H3C Tech. Co., Ltd. 4441 310 Liuhe Road, Zhijiang Science Park 4442 Hangzhou, 310053 4443 P.R.China 4445 Phone: +86 571 86760000 4446 Email: chuanhuang_li@zjsu.edu.cn 4448 Halpern Joel 4449 Ericsson 4450 P.O. Box 6049 4451 Leesburg, 20178 4452 VA 4454 Phone: +1 703 371 3043 4455 Email: joel.halpern@ericsson.com