idnits 2.17.1 draft-ietf-forces-lfb-lib-08.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 == Line 1479 has weird spacing: '...ut port for o...' == Line 3441 has weird spacing: '...packets accor...' == Line 3716 has weird spacing: '...ion has occur...' == Line 4437 has weird spacing: '...nes are appli...' -- The document date (February 29, 2012) is 4437 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 4900, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 4909, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 4912, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 4916, 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 (~~), 10 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: September 1, 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 February 29, 2012 14 ForCES Logical Function Block (LFB) Library 15 draft-ietf-forces-lfb-lib-08 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 September 1, 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 . . . . . . . . . . . . . . . . . . . . 43 80 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 43 81 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 44 82 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 46 83 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 47 84 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 50 85 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 52 86 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 53 87 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 53 88 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55 89 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 56 90 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 57 91 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 59 92 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 61 93 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 63 94 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 65 95 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 65 96 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 66 97 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 67 98 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 67 99 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 68 100 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 71 101 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 100 102 7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 100 103 7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 101 104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 104 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 107 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 106 108 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 108 109 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 108 110 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 109 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 111 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 112 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 112 114 12.2. Informative References . . . . . . . . . . . . . . . . . 112 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113 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 type 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 type 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 LAN speed by value types 543 DuplexType Duplex types 544 PortStatusType The possible types 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 IPv4UcastLPM LFB 571 IPv6UcastLPMStatsType Statistics type in IPv6UcastLPM 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 type 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 Metadata indicating a physical port ID 628 SrcMAC 2 Metadata indicating a source MAC address 629 DstMAC 3 Metadata indicating a destination MAC 630 address. 631 LogicalPortID 4 Metadata of a logical port ID 632 EtherType 5 Metadata indicating an Ethernet type 633 VlanID 6 Metadata of a VLAN ID 634 VlanPriority 7 Metadata of a VLAN priority 635 NextHopIPv4Addr 8 Metadata representing a next hop IPv4 636 address. 637 NextHopIPv6Addr 9 Metadata representing a next hop IPv6 638 address. 639 HopSelector 10 Metadata indicating a hop selector 640 ExceptionID 11 Metadata indicating exception types for 641 exceptional cases during LFB processing. 642 ValidateErrorID 12 Metadata indicating error types when a 643 packet passes validation process. 644 L3PortID 13 Metadata indicating ID of an L3 logical 645 port. 646 RedirectIndex 14 Metadata that CE sends to RedirectIn LFB, 647 indicating an associated packet a group 648 output port index of the LFB. 649 MediaEncapInfoIndex 15 A search key a packet uses to look up a 650 table in related LFBs to select an 651 encapsulation media. 653 4.4. XML for Base Type Library 655 656 659 660 661 EthernetAll 662 Any type 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 type 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 LAN speed by value types 720 721 uint32 722 723 724 LAN_SPEED_NONE 725 Nothing is connected 726 727 728 LAN_SPEED_10M 729 10M Ethernet 730 731 732 LAN_SPEED_100M 733 100M Ethernet 734 735 736 LAN_SPEED_1G 737 1G Ethernet 738 739 740 LAN_SPEED_10G 741 10G Ethernet 742 743 744 LAN_SPEED_AUTO 745 LAN speed by auto negotiation 746 747 748 749 750 751 DuplexType 752 Duplex types 753 754 uint32 755 756 757 Auto 758 Auto negotiation 759 760 761 HalfDuplex 762 Half duplex 763 764 765 FullDuplex 766 Full duplex 767 769 770 771 772 773 PortStatusType 774 775 Data types for port status, used for both administrative and 776 operative status. 777 778 779 uchar 780 781 782 Disabled 783 Port is operatively disabled 784 785 786 Up 787 Port is up 788 789 790 Down 791 Port is down 792 793 794 795 796 797 MACInStatsType 798 799 Data types for statistics in EtherMACIn LFB 800 801 802 803 NumPacketsReceived 804 Number of packets received 805 uint64 806 807 808 NumPacketsDropped 809 Number of packets dropped 810 uint64 811 812 813 814 815 MACOutStatsType 816 817 Data types for statistics in EtherMACOut LFB 818 819 820 821 NumPacketsTransmitted 822 Number of packets transmitted 823 uint64 824 825 826 NumPacketsDropped 827 Number of packets dropped 828 uint64 829 830 831 832 833 EtherDispatchEntryType 834 835 Data type for entry of Ethernet dispatch table in 836 EtherClassifier LFB. 837 838 839 840 LogicalPortID 841 Logical port ID 842 uint32 843 844 845 EtherType 846 847 Ethernet type as defined in Ethernet frame header 848 849 uint32 850 851 852 LFBOutputSelectIndex 853 854 Index for a packet to select a port instance in 855 EtherClassifier LFB group output port to link to a 856 downstream LFB. Possible downstream LFBs are 857 IPv4Validator, IPv6Validator, RedirectOut, etc. 858 859 uint32 860 861 862 863 864 EtherDispatchTableType 865 866 Data type for Ethernet dispatch table in EtherClassifier 867 LFB. The table entry type is defined by 868 EtherDispatchEntryType. 869 870 871 EtherDispatchEntryType 872 873 874 875 VlanIDType 876 Data type for VLAN ID 877 878 uint16 879 880 881 882 883 884 885 VlanPriorityType 886 Data type for VLAN priority 887 888 uchar 889 890 891 892 893 894 895 VlanInputTableEntryType 896 897 Data type for entry of VLAN input table in EtherClassifier 898 LFB. 899 900 901 902 IncomingPortID 903 The incoming port ID 904 uint32 905 906 907 VlanID 908 The VLAN ID 909 VlanIDType 910 911 912 Reserved 913 Reserved for future use 914 uint16 916 917 918 LogicalPortID 919 The logical port ID 920 uint32 921 922 923 924 925 VlanInputTableType 926 927 Data type for VlanInputTable in EtherClassifier LFB. The 928 entry type is defined by VlanInputTableEntryType. Each row 929 of the table is a struct containing an Incoming Port ID, a 930 VLAN ID and a Logical Port ID. Every input packet is 931 assigned with a new LogicalPortID according to the packet 932 incoming port ID and the VLAN ID. Then, the 933 EtherDispatchTable in the LFB dispatches every Ethernet 934 packet to different output according to the logical port ID 935 assigned by the VlanInputTable to the packet and the 936 Ethernet type in the Ethernet packet header. 937 938 939 VlanInputTableEntryType 940 941 942 943 EtherClassifyStatsType 944 945 Data type for entry of statistics table in EtherClassifier 946 LFB. 947 948 949 950 EtherType 951 952 The Ethernet type as defined in Ethernet packet header 953 954 uint32 955 956 957 PacketsNum 958 Packets number 959 uint64 960 962 963 964 965 EtherClassifyStatsTableType 966 967 Data type for Ethernet classifying statistics table in 968 EtherClassifier LFB, the entry of which is defined by 969 EtherClassifyStatsType. 970 971 972 EtherClassifyStatsType 973 974 975 976 IPv4ValidatorStatsType 977 978 Data type for statistics in IPv4validator LFB 979 980 981 982 badHeaderPkts 983 Number of bad header packets 984 uint64 985 986 987 badTotalLengthPkts 988 989 Number of packets with bad total length 990 991 uint64 992 993 994 badTTLPkts 995 Number of bad TTL packets 996 uint64 997 998 999 badChecksumPkts 1000 Number of bad checksum packets 1001 uint64 1002 1003 1004 1005 1006 IPv6ValidatorStatsType 1007 1008 Data type for statistics in IPv6validator LFB 1009 1010 1011 1012 badHeaderPkts 1013 Number of bad header packets 1014 uint64 1015 1016 1017 badTotalLengthPkts 1018 Number of bad total length packets 1019 uint64 1020 1021 1022 badHopLimitPkts 1023 Number of bad hop limit packets 1024 uint64 1025 1026 1027 1028 1029 IPv4PrefixInfoType 1030 Data type for entry of IPv4 prefix table 1031 1032 1033 IPv4Address 1034 The IPv4 address 1035 IPv4Addr 1036 1037 1038 Prefixlen 1039 The prefix length 1040 1041 uchar 1042 1043 1044 1045 1046 1047 1048 ECMPFlag 1049 ECMP flag 1050 1051 boolean 1052 1053 1054 False 1055 1056 ECMP flag is false, indicating the route 1057 does not have multiple next hops. 1059 1060 1061 1062 True 1063 1064 ECMP flag is true, indicating the route 1065 has multiple next hops. 1066 1067 1068 1069 1070 1071 1072 DefaultRouteFlag 1073 Default route flag 1074 1075 boolean 1076 1077 1078 False 1079 1080 Default route flag is false, indicating the 1081 route is not a default route. 1082 1083 1084 1085 True 1086 1087 Default route flag is true, indicating the 1088 route is a default route. 1089 1090 1091 1092 1093 1094 1095 Reserved 1096 Reserved for future use 1097 uchar 1098 1099 1100 HopSelector 1101 1102 HopSelector is produced by the prefix match LFB and 1103 output to downstream LFBs as a next hop information 1104 identifier. 1105 1106 uint32 1108 1109 1110 1111 1112 IPv4PrefixTableType 1113 1114 Data type for IPv4 longest prefix match table used for 1115 IPv4UcastLPM LFB. The destination IPv4 address of every 1116 input packet is used as a search key to look up the table 1117 to find out a next hop selector. Entry type of the table is 1118 defined by IPv4PrefixInfoType. 1119 1120 1121 IPv4PrefixInfoType 1122 1123 1124 1125 IPv4UcastLPMStatsType 1126 Statistics type in IPv4UcastLPM LFB 1127 1128 1129 InRcvdPkts 1130 1131 Total number of input packets received 1132 1133 uint64 1134 1135 1136 FwdPkts 1137 Packets forwarded by the LFB 1138 uint64 1139 1140 1141 NoRoutePkts 1142 Packets with no routes found 1143 uint64 1144 1145 1146 1147 1148 IPv6PrefixInfoType 1149 Entry type for IPv6 prefix table 1150 1151 1152 IPv6Address 1153 The IPv6 address 1154 IPv6Addr 1155 1156 1157 Prefixlen 1158 The prefix length 1159 1160 uchar 1161 1162 1163 1164 1165 1166 1167 ECMPFlag 1168 ECMP flag 1169 1170 boolean 1171 1172 1173 False 1174 1175 ECMP flag is false, indicating the route 1176 does not have multiple next hops. 1177 1178 1179 1180 True 1181 1182 ECMP flag is true, indicating the route has 1183 multiple next hops. 1184 1185 1186 1187 1188 1189 1190 DefaultRouteFlag 1191 Default route flag 1192 1193 boolean 1194 1195 1196 False 1197 1198 Default route flag is false, indicating the 1199 route is not a default route. 1200 1201 1202 1203 True 1204 1205 Default route flag is true, indicating the 1206 route is a default route. 1207 1208 1209 1210 1211 1212 1213 Reserved 1214 Reserved for future use 1215 uchar 1216 1217 1218 HopSelector 1219 1220 HopSelector is produced by the prefix match LFB and 1221 output to downstream LFBs as a next hop information 1222 identifier. 1223 1224 uint32 1225 1226 1227 1228 1229 IPv6PrefixTableType 1230 1231 Data type for IPv6 longest prefix match table used for 1232 IPv6UcastLPM LFB. The destination IPv6 address of every 1233 input packet is used as a search key to look up the table 1234 to find out a next hop selector. Entry type of the table is 1235 defined by IPv6PrefixInfoType. 1236 1237 1238 IPv6PrefixInfoType 1239 1240 1241 1242 IPv6UcastLPMStatsType 1243 Statistics type in IPv6UcastLPM LFB 1244 1245 1246 InRcvdPkts 1247 1248 Total number of input packets received 1249 1250 uint64 1251 1252 1253 FwdPkts 1254 Packets forwarded by the LFB 1255 uint64 1256 1257 1258 NoRoutePkts 1259 Packets with no routes found 1260 uint64 1261 1262 1263 1264 1265 IPv4NextHopInfoType 1266 1267 Data type for entry of IPv4 next hop information table used 1268 in IPv4NextHop LFB. 1269 1270 1271 1272 L3PortID 1273 1274 The L3PortID is the ID of the logical output port 1275 that is passed onto the downstream LFB, indicating 1276 what port to the neighbor is as defined by L3. 1277 1278 uint32 1279 1280 1281 MTU 1282 1283 Maximum Transmission Unit for outgoing port 1284 1285 uint32 1286 1287 1288 NextHopIPAddr 1289 Next hop IPv4 address 1290 IPv4Addr 1291 1292 1293 MediaEncapInfoIndex 1294 1295 The index is passed onto the downstream encapsulation 1296 LFB instance and is used there as a search key to 1297 lookup the index of a table (typically media 1298 encapsulation related) for further encapsulation 1299 information. 1301 1302 uint32 1303 1304 1305 LFBOutputSelectIndex 1306 1307 The index is for the LFB Group output port to select 1308 downstream LFB port. It is a 1-to-1 mapping with 1309 FEObject LFB's table LFBTopology component 1310 FromPortIndex corresponding to the port group mapping 1311 FromLFBID as IPv4NextHop LFB instance. 1312 1313 uint32 1314 1315 1316 1317 1318 IPv4NextHopTableType 1319 1320 Data type for IPv4 next hop table in IPv4NextHop LFB. The 1321 LFB uses a hop selector metadata received from upstream LFB 1322 as a search key to look up the index of the table to get 1323 next hop information. Entry type of the table is defined by 1324 IPv4NextHopInfoType. 1325 1326 1327 IPv4NextHopInfoType 1328 1329 1330 1331 IPv6NextHopInfoType 1332 1333 Data type for entry of IPv6 next hop information table used 1334 in IPv6NextHop LFB. 1335 1336 1337 1338 L3PortID 1339 1340 The L3PortID is the ID of the logical output port 1341 that is passed onto the downstream LFB, indicating 1342 what port to the neighbor is as defined by L3. 1343 1344 uint32 1345 1346 1347 MTU 1348 1349 Maximum Transmission Unit for outgoing port 1350 1351 uint32 1352 1353 1354 NextHopIPAddr 1355 Next hop IPv6 address 1356 IPv6Addr 1357 1358 1359 MediaEncapInfoIndex 1360 1361 The index is passed onto the downstream encapsulation 1362 LFB instance and is used there as a search key to 1363 lookup the index of a table (typically media 1364 encapsulation related) for further encapsulation 1365 information. 1366 1367 uint32 1368 1369 1370 LFBOutputSelectIndex 1371 1372 The index is for the LFB group output port to select 1373 downstream LFB port. It is a 1-to-1 mapping with 1374 FEObject LFB's table LFBTopology component 1375 FromPortIndex corresponding to the port group mapping 1376 FromLFBID as IPv6NextHop LFB instance. 1377 1378 uint32 1379 1380 1381 1382 1383 IPv6NextHopTableType 1384 1385 Data type for IPv6 next hop table in IPv6NextHop LFB. The 1386 LFB uses a hop selector metadata received from upstream LFB 1387 as a search key to look up the index of the table to get 1388 next hop information. Entry type of the table is defined by 1389 IPv6NextHopInfoType. 1390 1391 1392 IPv6NextHopInfoType 1393 1394 1395 1396 EncapTableEntryType 1397 1398 Data type for entry of Ethernet encapsulation table in 1399 EtherEncap LFB. 1400 1401 1402 1403 DstMac 1404 1405 Destination MAC address for Ethernet encapsulation of 1406 the packet. 1407 1408 IEEEMAC 1409 1410 1411 SrcMac 1412 1413 Source MAC address for Ethernet encapsulation of the 1414 packet. 1415 1416 IEEEMAC 1417 1418 1419 VlanID 1420 The VLAN ID assigned to the packet 1421 VlanIDType 1422 1423 1424 Reserved 1425 Reserved for future use 1426 uint16 1427 1428 1429 L2PortID 1430 1431 The L2 logical output port ID for the packet 1432 1433 uint32 1434 1435 1436 1437 1438 EncapTableType 1439 1440 Data type for Ethernet encapsulation table in Etherencap 1441 LFB. The LFB uses the metadata "MediaEncapInfoIndex" 1442 received from upstream LFB as the index of the table to 1443 get encapsulation information of every packet.Entry type 1444 of the table is defined by EncapTableEntryType. 1446 1447 1448 EncapTableEntryType 1449 1450 1451 1452 MetadataDispatchType 1453 1454 Data type for entry of metadata dispatch table used 1455 in BasicMetadataDispatch LFB. 1456 1457 1458 1459 MetadataValue 1460 The value of the dispatch metadata 1461 uint32 1462 1463 1464 OutputIndex 1465 1466 Index of a group output port for outgoing packets 1467 with the dispatch metadata value. 1468 1469 uint32 1470 1471 1472 1473 1474 MetadataDispatchTableType 1475 1476 Data type for metadata dispatch table used in 1477 BasicMetadataDispatch LFB. The LFB uses a metadata value as 1478 the search key to look up the table to get an index of the 1479 LFB group output port for output of the packet. Metadata 1480 value of the table is also defined as a content key field so 1481 that CE can manipulate the table by means of a content key. 1482 1483 1484 MetadataDispatchType 1485 1486 MetadataValue 1487 1488 1489 1490 1491 SchdDisciplineType 1492 Scheduling discipline types 1493 1494 uint32 1495 1496 1497 RR 1498 1499 Round Robin scheduling discipline 1500 1501 1502 1503 1504 1505 1506 QueueStatsType 1507 1508 Data type for entry of queue statistics table in 1509 GenericScheduler LFB. 1510 1511 1512 1513 QueueID 1514 The input queue ID 1515 uint32 1516 1517 1518 QueueDepthInPackets 1519 Current queue depth in packets 1520 uint32 1521 1522 1523 QueueDepthInBytes 1524 Current queue depth in bytes 1525 uint32 1526 1527 1528 1529 1530 QueueStatsTableType 1531 1532 Data type for queue statistics table in GenericScheduler 1533 LFB. Entry type of the table is defined by QueueStatsType. 1534 1535 1536 QueueStatsType 1537 1538 1539 1540 1541 1542 PHYPortID 1543 Metadata indicating a physical port ID 1544 1 1545 uint32 1546 1547 1548 SrcMAC 1549 Metadata indicating a source MAC address 1550 2 1551 IEEEMAC 1552 1553 1554 DstMAC 1555 1556 Metadata indicating a destination MAC address 1557 1558 3 1559 IEEEMAC 1560 1561 1562 LogicalPortID 1563 Metadata of a logical port ID 1564 4 1565 uint32 1566 1567 1568 EtherType 1569 Metadata indicating an Ethernet type 1570 5 1571 uint32 1572 1573 1574 VlanID 1575 Metadata of a VLAN ID 1576 6 1577 VlanIDType 1578 1579 1580 VlanPriority 1581 Metadata of a VLAN priority 1582 7 1583 VlanPriorityType 1584 1585 1586 NextHopIPv4Addr 1587 1588 Metadata representing a next hop IPv4 address 1589 1590 8 1591 IPv4Addr 1592 1593 1594 NextHopIPv6Addr 1595 1596 Metadata representing a next hop IPv6 address 1597 1598 9 1599 IPv6Addr 1600 1601 1602 HopSelector 1603 Metadata indicating a hop selector 1604 10 1605 uint32 1606 1607 1608 ExceptionID 1609 1610 Metadata indicating exception types for exceptional cases 1611 during LFB processing. 1612 1613 11 1614 1615 uint32 1616 1617 1618 AnyUnrecognizedExceptionCase 1619 Any unrecognized exception case 1620 1621 1622 ClassifyNoMatching 1623 1624 There is no matching of tables in EtherClassifier 1625 LFB. 1626 1627 1628 1629 MediaEncapInfoIndexInvalid 1630 1631 The MediaEncapInfoIndex value of the packet is 1632 invalid and cannot be allocated in the EncapTable 1633 in EtherEncap LFB. 1634 1635 1636 1637 EncapTableLookupFailed 1638 1639 The packet failed lookup of the EncapTable table 1640 in EtherEncap LFB even though the 1641 MediaEncapInfoIndex is valid. 1642 1643 1644 1645 BadTTL 1646 Packet with expired TTL 1647 1648 1649 IPv4HeaderLengthMismatch 1650 1651 Packet with header length more than 5 words 1652 1653 1654 1655 RouterAlertOptions 1656 1657 Packet IP head includes router alert Options 1658 1659 1660 1661 IPv6HopLimitZero 1662 Packet with the hop limit zero 1663 1664 1665 IPv6NextHeaderHBH 1666 1667 Packet with next header set to Hop-by-Hop 1668 1669 1670 1671 SrcAddressExecption 1672 1673 Packet with exceptional source address 1674 1675 1676 1677 DstAddressExecption 1678 1679 Packet with exceptional destination address 1680 1681 1682 1683 LPMLookupFailed 1684 1685 Packet failed the LPM table lookup in a prefix 1686 match LFB. 1687 1688 1689 1690 HopSelectorInvalid 1691 1692 HopSelector for the packet is invalid 1693 1694 1695 1696 NextHopLookupFailed 1697 1698 Packet failed lookup of a next hop table even 1699 though HopSelector is valid. 1700 1701 1702 1703 FragRequired 1704 1705 Packet fragmentation is required 1706 1707 1708 1709 MetadataNoMatching 1710 1711 There is no matching when looking up the metadata 1712 dispatch table in BasicMetadataDispatch LFB. 1713 1714 1715 1716 1717 1718 1719 ValidateErrorID 1720 1721 Metadata indicating error types when a packet passes 1722 validation process. 1723 1724 12 1725 1726 uint32 1727 1728 1729 AnyUnrecognizedValidateErrorCase 1730 1731 Any unrecognized validate error case 1732 1733 1734 1735 InvalidIPv4PacketSize 1736 1737 Packet length reported by the link layer is less 1738 than 20 bytes. 1739 1740 1741 1742 NotIPv4Packet 1743 Packet is not IP version 4 1744 1745 1746 InvalidIPv4HeaderLengthSize 1747 1748 Packet with header length field in the header 1749 less than 5 words. 1750 1751 1752 1753 InvalidIPv4LengthFieldSize 1754 1755 Packet with total length field in the header less 1756 than 20 bytes. 1757 1758 1759 1760 InvalidIPv4Checksum 1761 Packet with invalid checksum 1762 1763 1764 InvalidIPv4SrcAddr 1765 1766 Packet with invalid IPv4 source address 1767 1768 1769 1770 InvalidIPv4DstAddr 1771 1772 Packet with invalid IPv4 destination address 1773 1774 1775 1776 InvalidIPv6PacketSize 1777 1778 Packet size is less than 40 bytes 1779 1780 1781 1782 NotIPv6Packet 1783 Packet is not IP version 6 1784 1785 1786 InvalidIPv6SrcAddr 1787 1788 Packet with invalid IPv6 source address 1789 1790 1791 1792 InvalidIPv6DstAddr 1793 1794 Packet with invalid IPv6 destination address 1795 1796 1797 1798 1799 1800 1801 L3PortID 1802 1803 Metadata indicating ID of an L3 logical port 1804 1805 13 1806 uint32 1807 1808 1809 RedirectIndex 1810 1811 Metadata that CE sends to RedirectIn LFB, indicating an 1812 associated packet a group output port index of the LFB. 1813 1814 14 1815 uint32 1816 1817 1818 MediaEncapInfoIndex 1819 1820 A search key a packet uses to look up a table in related 1821 LFBs to select an encapsulation media. 1822 1823 15 1824 uint32 1825 1826 1827 1829 5. LFB Class Description 1831 According to ForCES specifications, LFB (Logical Function Block) is a 1832 well defined, logically separable functional block that resides in an 1833 FE, and is a functionally accurate abstraction of the FE's processing 1834 capabilities. An LFB Class (or type) is a template that represents a 1835 fine-grained, logically separable aspect of FE processing. Most LFBs 1836 are related to packet processing in the data path. LFB classes are 1837 the basic building blocks of the FE model. Note that [RFC5810] has 1838 already defined an 'FE Protocol LFB' which is a logical entity in 1839 each FE to control the ForCES protocol. [RFC5812] has already 1840 defined an 'FE Object LFB'. Information like the FE Name, FE ID, FE 1841 State, LFB Topology in the FE are represented in this LFB. 1843 As specified in Section 3.1, this document focuses on the base LFB 1844 library for implementing typical router functions, especially for IP 1845 forwarding functions. As a result, LFB classes in the library are 1846 all base LFBs to implement router forwarding. 1848 In this section, the terms "upstream LFB" and "downstream LFB" are 1849 used. These are used relative to an LFB to an LFB that is being 1850 described. An "upstream LFB" is one whose output ports are connected 1851 to input ports of the LFB under consideration such that output 1852 (typically packets with metadata) can be sent from the "upstream LFB" 1853 to the LFB under consideration. Similarly, a "downstream LFB" whose 1854 input ports are connected to output ports of the LFB under 1855 consideration such that the LFB under consideration can send 1856 information to the "downstream LFB". Note that in some rare 1857 topologies, an LFB may be both upstream and downstream relative to 1858 another LFB. 1860 Also note that, as a default provision of [RFC5812], in FE model, all 1861 metadata produced by upstream LFBs will pass through all downstream 1862 LFBs by default without being specified by input port or output port. 1863 Only those metadata that will be used (consumed) by an LFB will be 1864 explicitly marked in input of the LFB as expected metadata. For 1865 instance, in downstream LFBs of a physical layer LFB, even there is 1866 no specific metadata expected, metadata like PHYPortID produced by 1867 the physical layer LFB will always pass through all downstream LFBs 1868 regardless of whether the metadata has been expected by the LFBs or 1869 not. 1871 5.1. Ethernet Processing LFBs 1873 As the most popular physical and data link layer protocols, Ethernet 1874 is widely deployed. It becomes a basic requirement for a router to 1875 be able to process various Ethernet data packets. 1877 Note that there exist different versions of Ethernet formats, like 1878 Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP. 1879 There also exist varieties of LAN techniques based on Ethernet, like 1880 various VLANs, MACinMAC, etc. Ethernet processing LFBs defined here 1881 are intended to be able to cope with all these variations of Ethernet 1882 technology. 1884 There are also various types of Ethernet physical interface media. 1885 Among them, copper and fiber media may be the most popular ones. As 1886 a base LFB definition and a starting point, the document only defines 1887 an Ethernet physical LFB with copper media. For other media 1888 interfaces, specific LFBs may be defined in the future versions of 1889 the library. 1891 5.1.1. EtherPHYCop 1893 EtherPHYCop LFB abstracts an Ethernet interface physical layer with 1894 media limited to copper. 1896 5.1.1.1. Data Handling 1898 This LFB is the interface to the Ethernet physical media. The LFB 1899 handles Ethernet frames coming in from or going out of the FE. 1900 Ethernet frames sent and received cover all packets encapsulated with 1901 different versions of Ethernet protocols, like Ethernet V2, 802.3 1902 RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets 1903 encapsulated with varieties of LAN techniques based on Ethernet, like 1904 various VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll 1905 frame type has been introduced. 1907 Ethernet frames are received from the physical media port and passed 1908 downstream to LFBs such as EtherMACIn via a singleton output known as 1909 "EtherPHYOut". A 'PHYPortID' metadata, to indicate which physical 1910 port the frame came into from the external world, is passed along 1911 with the frame. 1913 Ethernet packets are received by this LFB from upstream LFBs such as 1914 EtherMacOut LFBs via the singleton input known as "EtherPHYIn" before 1915 being sent out onto the external world. 1917 5.1.1.2. Components 1919 The AdminStatus component is defined for CE to administratively 1920 manage the status of the LFB. The CE may administratively startup or 1921 shutdown the LFB by changing the value of AdminStatus. The default 1922 value is set to 'Down'. 1924 An OperStatus component captures the physical port operational 1925 status. A PHYPortStatusChanged event is defined so the LFB can 1926 report to the CE whenever there is an operational status change of 1927 the physical port. 1929 The PHYPortID component is a unique identification for a physical 1930 port. It is defined as 'read-only' by CE. Its value is enumerated 1931 by FE. The component will be used to produce a 'PHYPortID' metadata 1932 at the LFB output and to associate it to every Ethernet packet this 1933 LFB receives. The metadata will be handed to downstream LFBs for 1934 them to use the PHYPortID. 1936 A group of components are defined for link speed management. The 1937 AdminLinkSpeed is for CE to configure link speed for the port and the 1938 OperLinkSpeed is for CE to query the actual link speed in operation. 1939 The default value for the AdminLinkSpeed is set to auto-negotiation 1940 mode. 1942 A group of components are defined for duplex mode management. The 1943 AdminDuplexMode is for CE to configure proper duplex mode for the 1944 port and the OperDuplexMode is for CE to query the actual duplex mode 1945 in operation. The default value for the AdminDuplexMode is set to 1946 auto-negotiation mode. 1948 A CarrierStatus component captures the status of the carrier and 1949 specifies whether the port link is operationally up. The default 1950 value for the CarrierStatus is 'false'. 1952 5.1.1.3. Capabilities 1954 The capability information for this LFB includes the link speeds that 1955 are supported by the FE (SupportedLinkSpeed) as well as the supported 1956 duplex modes (SupportedDuplexMode). 1958 5.1.1.4. Events 1960 Several events are generated. There is an event for changes in the 1961 status of the physical port (PhyPortStatusChanged). Such an event 1962 will notify that the physical port status has been changed and the 1963 report will include the new status of the physical port. 1965 Another event captures changes in the operational link speed 1966 (LinkSpeedChanged). Such an event will notify the CE that the 1967 operational speed has been changed and the report will include the 1968 new negotiated operational speed. 1970 A final event captures changes in the duplex mode 1971 (DuplexModeChanged). Such an event will notify the CE that the 1972 duplex mode has been changed and the report will include the new 1973 negotiated duplex mode. 1975 5.1.2. EtherMACIn 1977 EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. 1978 This LFB describes Ethernet processing functions like MAC address 1979 locality check, deciding if the Ethernet packets should be bridged, 1980 providing Ethernet layer flow control, etc. 1982 5.1.2.1. Data Handling 1984 The LFB is expected to receive all types of Ethernet packets, via a 1985 singleton input known as "EtherPktsIn", which are usually output from 1986 some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside 1987 with a metadata indicating the physical port ID that the packet 1988 arrived on. 1990 The LFB is defined with two separate singleton outputs. All Output 1991 packets are emitted in the original Ethernet format received at the 1992 physical port, unchanged, and cover all types of Ethernet types. 1994 The first singleton output is known as "NormalPathOut". It usually 1995 outputs Ethernet packets to some LFB like an EtherClassifier LFB for 1996 further L3 forwarding process alongside with a PHYPortID metadata 1997 indicating which physical port the packet came from. 1999 The second singleton output is known as "L2BridgingPathOut". 2000 Although the LFB library this document defines is basically to meet 2001 typical router functions, it will attempt to be forward compatible 2002 with future router functions. The "L2BridgingPathOut" is defined to 2003 meet the requirement that L2 bridging functions may be optionally 2004 supported simultaneously with L3 processing and some L2 bridging LFBs 2005 that may be defined in the future. If the FE supports L2 bridging, 2006 the CE can enable or disable it by means of a "L2BridgingPathEnable" 2007 component in the FE. If it is enabled, by also instantiating some L2 2008 bridging LFB instances following the L2BridgingPathOut, FEs are 2009 expected to fulfill L2 bridging functions. L2BridgingPathOut will 2010 output packets exactly the same as that in the NormalPathOut output. 2012 This LFB can be set to work in a Promiscuous Mode, allowing all 2013 packets to pass through the LFB without being dropped. Otherwise, a 2014 locality check will be performed based on the local MAC addresses. 2015 All packets that do not pass through the locality check will be 2016 dropped. 2018 This LFB participates in Ethernet flow control in cooperation with 2019 EtherMACOut LFB. This document does not go into the details of how 2020 this is implemented; the reader may refer to some relevant 2021 references. This document also does not describe how the buffers 2022 which induce the flow control messages behave - it is assumed that 2023 such artifacts exist and describing them is out of scope in this 2024 document. 2026 5.1.2.2. Components 2028 The AdminStatus component is defined for the CE to administratively 2029 manage the status of the LFB. The CE may administratively startup or 2030 shutdown the LFB by changing the value of AdminStatus. The default 2031 value is set to 'Down'. 2033 The LocalMACAddresses component specifies the local MAC addresses 2034 based on which locality checks will be made. This component is an 2035 array of MAC addresses, and of 'read-write' access permission. 2037 An L2BridgingPathEnable component captures whether the LFB is set to 2038 work as a L2 bridge. An FE that does not support bridging will 2039 internally set this flag to false, and additionally set the flag 2040 property as read-only. The default value for is 'false'. 2042 The PromiscuousMode component specifies whether the LFB is set to 2043 work as in a promiscuous mode. The default value for is 'false'. 2045 The TxFlowControl component defines whether the LFB is performing 2046 flow control on sending packets. The default value for is 'false'. 2048 The RxFlowControl component defines whether the LFB is performing 2049 flow control on receiving packets. The default value for is 'false'. 2051 A struct component, MACInStats, defines a set of statistics for this 2052 LFB, including the number of received packets and the number of 2053 dropped packets. 2055 5.1.2.3. Capabilities 2057 This LFB does not have a list of capabilities. 2059 5.1.2.4. Events 2061 This LFB does not have any events specified. 2063 5.1.3. EtherClassifier 2065 EtherClassifier LFB abstracts the process to decapsulate Ethernet 2066 packets and then classify them. 2068 5.1.3.1. Data Handling 2070 This LFB describes the process of decapsulating Ethernet packets and 2071 classifying them into various network layer data packets according to 2072 information included in the Ethernet packets headers. 2074 The LFB is expected to receive all types of Ethernet packets, via a 2075 singleton input known as "EtherPktsIn", which are usually output from 2076 an upstream LFB like EtherMACIn LFB. This input is also capable of 2077 multiplexing to allow for multiple upstream LFBs being connected. 2078 For instance, when L2 bridging function is enabled in EtherMACIn LFB, 2079 some L2 bridging LFBs may be applied. In this case, some Ethernet 2080 packets after L2 processing may have to be input to EtherClassifier 2081 LFB for classification, while simultaneously packets directly output 2082 from EtherMACIn may also need to input to this LFB. This input is 2083 capable of handling such a case. Usually, all expected Ethernet 2084 Packets will be associated with a PHYPortID metadata, indicating the 2085 physical port the packet comes from. In some cases, for instance, 2086 like in a MACinMAC case, a LogicalPortID metadata may be expected to 2087 associate with the Ethernet packet to further indicate which logical 2088 port the Ethernet packet belongs to. Note that PHYPortID metadata is 2089 always expected while LogicalPortID metadata is optionally expected. 2091 Two output LFB ports are defined. 2093 The first output is a group output port known as "ClassifyOut". 2094 Types of network layer protocol packets are output to instances of 2095 the port group. Because there may be various type of protocol 2096 packets at the output ports, the produced output frame is defined as 2097 arbitrary for the purpose of wide extensibility in the future. 2098 Metadata to be carried along with the packet data is produced at this 2099 LFB for consumption by downstream LFBs. The metadata passed 2100 downstream includes PHYPortID, as well as information on Ethernet 2101 type, source MAC address, destination MAC address and the logical 2102 port ID. If the original packet is a VLAN packet and contains a VLAN 2103 ID and a VLAN priority value, then the VLAN ID and the VLAN priority 2104 value are also carried downstream as metadata. As a result, the VLAN 2105 ID and priority metadata are defined with the availability of 2106 "conditional". 2108 The second output is a singleton output port known as "ExceptionOut", 2109 which will output packets for which the data processing failed, along 2110 with an additional ExceptionID metadata to indicate what caused the 2111 exception. Currently defined exception types include: 2113 o There is no matching when classifying the packet. 2115 Usually the exception out port may point to no where, indicating 2116 packets with exceptions are dropped, while in some cases, the output 2117 may be pointed to the path to the CE for further processing, 2118 depending on individual implementations. 2120 5.1.3.2. Components 2122 An EtherDispatchTable array component is defined in the LFB to 2123 dispatch every Ethernet packet to the output group according to the 2124 logical port ID assigned by the VlanInputTable to the packet and the 2125 Ethernet type in the Ethernet packet header. Each row of the array 2126 is a struct containing a Logical Port ID, an EtherType and an Output 2127 Index. With the CE configuring the dispatch table, the LFB can be 2128 expected to classify various network layer protocol type packets and 2129 output them at different output ports. It is expected that the LFB 2130 classify packets according to protocols like IPv4, IPv6, MPLS, ARP, 2131 ND, etc. 2133 A VlanInputTable array component is defined in the LFB to classify 2134 VLAN Ethernet packets. Each row of the array is a struct containing 2135 an Incoming Port ID, a VLAN ID and a Logical Port ID. According to 2136 IEEE VLAN specifications, all Ethernet packets can be recognized as 2137 VLAN types by defining that if there is no VLAN encapsulation in a 2138 packet, a case with VLAN tag 0 is considered. Every input packet is 2139 assigned with a new LogicalPortID according to the packet incoming 2140 port ID and the VLAN ID. A packet incoming port ID is defined as a 2141 logical port ID if a logical port ID is associated with the packet, 2142 or a physical port ID if no logical port ID associated. The VLAN ID 2143 is exactly the VLAN ID in the packet if it is a VLAN packet, or 0 if 2144 it is not. Note that a logical port ID of a packet may be rewritten 2145 with a new one by the VlanInputTable processing. 2147 Note that the logical port ID and physical port ID mentioned above 2148 are all originally configured by CE, and are globally effective 2149 within a ForCES NE (Network Element). To distinguish a physical port 2150 ID from a logical port ID in the incoming port ID field of the 2151 VlanInputTable, physical port ID and logical port ID must be assigned 2152 with separate number spaces. 2154 An array component, EtherClassifyStats, defines a set of statistics 2155 for this LFB, measuring the number of packets per EtherType. Each 2156 row of the array is a struct containing an EtherType and a Packet 2157 number. 2159 5.1.3.3. Capabilities 2161 This LFB does not have a list of capabilities. 2163 5.1.3.4. Events 2165 This LFB has no events specified. 2167 5.1.4. EtherEncap 2169 The EtherEncap LFB abstracts the process to replace or attach 2170 appropriate Ethernet headers to the packet. 2172 5.1.4.1. Data Handling 2174 This LFB abstracts the process of encapsulating Ethernet headers onto 2175 received packets. The encapsulation is based on passed metadata. 2177 The LFB is expected to receive IPv4 and IPv6 packets, via a singleton 2178 input port known as "EncapIn" which may be connected to an upstream 2179 LFB like an IPv4NextHop, an IPv6NextHop, BasicMetadataDispatch, or 2180 any LFB which requires to output packets for Ethernet encapsulation. 2181 The LFB always expects from upstream LFBs the 2182 MedTableiaEncapInfoIndex metadata which is used as a search key to 2183 lookup the encapsulation table EncapTable by the search key matching 2184 the table index. An input packet may also optionally receive a VLAN 2185 priority metadata, indicating that the packet is originally with a 2186 priority value. The priority value will be loaded back to the packet 2187 when encapsulating. The optional VLAN priority metadata is defined 2188 with a default value 0. 2190 Two singleton output LFB ports are defined. 2192 The first singleton output known as "SuccessOut". Upon a successful 2193 table lookup, the destination and source MAC addresses, and the 2194 logical media port (L2PortID) are found in the matching table entry. 2195 The CE may set the VlanID in case VLANs are used. By default the 2196 table entry for VlanID of 0 is used as per IEEE rules. Whatever the 2197 value of VlanID is, if the input metadata VlanPriority is non-zero, 2198 the packet will have a VLAN tag. If the VlanPriority and the VlanID 2199 are all zero, there is no VLAN tag to this packet. After replacing 2200 or attaching the appropriate Ethernet headers to the packet is 2201 complete, the packet is passed out on the "SuccessOut" LFB port to a 2202 downstream LFB instance alongside with the L2PortID. 2204 The second singleton output known as "ExceptionOut", which will 2205 output packets for which the table lookup fails, along with an 2206 additional ExceptionID metadata. Currently defined exception types 2207 only include the following case: 2209 o The MediaEncapInfoIndex value of the packet is invalid and can not 2210 be allocated in the EncapTable. 2212 o The packet failed lookup of the EncapTable table even though the 2213 MediaEncapInfoIndex is valid. 2215 The upstream LFB may be programmed by the CE to pass along a 2216 MediaEncapInfoIndex that does not exist in the EncapTable. That is 2217 to allow for resolution of the L2 headers, if needed, to be made at 2218 the L2 encapsulation level in this case (Ethernet) via ARP, or ND (or 2219 other methods depending on the link layer technology) when a table 2220 miss occurs. 2222 For neighbor L2 header resolution(table miss exception), the 2223 processing LFB may pass this packet to the CE via the redirect LFB or 2224 FE software or another LFB instance for further resolution. In such 2225 a case the metadata NextHopIPv4Addr or NextHopIPv6Addr generated by 2226 next hop LFB is also passed to the exception handling. Such an IP 2227 address could be used to do activities such as ARP or ND by the 2228 handler it is passed to. 2230 The result of the L2 resolution is to update the EncapTable as well 2231 as the next hop LFB so subsequent packets do not fail EncapTable 2232 lookup. The EtherEncap LFB does not make any assumptions of how the 2233 EncapTable is updated by the CE (or whether ARP/ND is used 2234 dynamically or static maps exist). 2236 Downstream LFB instances could be either an EtherMACOut type or a 2237 BasicMetadataDispatch type. If the final packet L2 processing is 2238 possible to be on per-media-port basis or resides on a different FE 2239 or in cases where L2 header resolution is needed, then the model 2240 makes sense to use a BasicMetadataDispatch LFB to fan out to 2241 different LFB instances. If there is a direct egress port point, 2242 then the model makes sense to have a downstream LFB instance being an 2243 EtherMACOut. 2245 5.1.4.2. Components 2247 This LFB has only one component named EncapTable which is defined as 2248 an array. Each row of the array is a struct containing the 2249 destination MAC address, the source MAC address, the VLAN ID with a 2250 default value of zero and the output logical L2 port ID. 2252 5.1.4.3. Capabilities 2254 This LFB does not have a list of capabilities. 2256 5.1.4.4. Events 2258 This LFB does not have any events specified. 2260 5.1.5. EtherMACOut 2262 EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. 2263 This LFB describes Ethernet packet output process. Ethernet output 2264 functions are closely related to Ethernet input functions, therefore 2265 many components defined in this LFB are as aliases of EtherMACIn LFB 2266 components. 2268 5.1.5.1. Data Handling 2270 The LFB is expected to receive all types of Ethernet packets, via a 2271 singleton input known as "EtherPktsIn", which are usually output from 2272 an Ethernet encapsulation LFB, alongside with a metadata indicating 2273 the physical port ID that the packet will go through. 2275 The LFB is defined with a singleton output. All Output packets are 2276 in Ethernet format, possibly with various Ethernet types, alongside 2277 with a metadata indicating the physical port ID the packet is to go 2278 through. This output links to a downstream LFB that is usually an 2279 Ethernet physical LFB like EtherPHYcop LFB. 2281 This LFB participates in Ethernet flow control in cooperation with 2282 EtherMACIn LFB. This document does not go into the details of how 2283 this is implemented; the reader may refer to some relevant 2284 references. This document also does not describe how the buffers 2285 which induce the flow control messages behave - it is assumed that 2286 such artifacts exist and describing them is out of scope in this 2287 document. 2289 Note that as a base definition, functions like multiple virtual MAC 2290 layers are not supported in this LFB version. It may be supported in 2291 the future by defining a subclass or a new version of this LFB. 2293 5.1.5.2. Components 2295 The AdminStatus component is defined for CE to administratively 2296 manage the status of the LFB. The CE may administratively startup or 2297 shutdown the LFB by changing the value of AdminStatus. The default 2298 value is set to 'Down'. Note that this component is defined as an 2299 alias of the AdminStatus component in the EtherMACIn LFB. This 2300 infers that an EtherMACOut LFB usually coexists with an EtherMACIn 2301 LFB, both of which share the same administrative status management by 2302 CE. Alias properties as defined in the ForCES FE model [RFC5812] 2303 will be used by CE to declare the target component this alias refers, 2304 which include the target LFB class and instance IDs as well as the 2305 path to the target component. 2307 The MTU component defines the maximum transmission unit. 2309 The TxFlowControl component defines whether the LFB is performing 2310 flow control on sending packets. The default value for is 'false'. 2311 Note that this component is defined as an alias of TxFlowControl 2312 component in the EtherMACIn LFB. 2314 The RxFlowControl component defines whether the LFB is performing 2315 flow control on receiving packets. The default value for is 'false'. 2316 Note that this component is defined as an alias of RxFlowControl 2317 component in the EtherMACIn LFB. 2319 A struct component, MACOutStats, defines a set of statistics for this 2320 LFB, including the number of transmitted packets and the number of 2321 dropped packets. 2323 5.1.5.3. Capabilities 2325 This LFB does not have a list of capabilities. 2327 5.1.5.4. Events 2329 This LFB does not have any events specified. 2331 5.2. IP Packet Validation LFBs 2333 The LFBs are defined to abstract IP packet validation process. An 2334 IPv4Validator LFB is specifically for IPv4 protocol validation and an 2335 IPv6Validator LFB for IPv6. 2337 5.2.1. IPv4Validator 2339 The IPv4Validator LFB performs IPv4 packets validation according to 2340 [RFC5812]. 2342 5.2.1.1. Data Handling 2344 This LFB performs IPv4 validation according to [RFC5812]. The IPv4 2345 packet will be output to the corresponding LFB port the indication 2346 whether the packet is unicast, multicast or whether an exception has 2347 occurred or the validation failed. 2349 This LFB always expects, as input, packets which have been indicated 2350 as IPv4 packets by an upstream LFB, like an EtherClassifier LFB. 2351 There is no specific metadata expected by the input of the LFB. 2353 Four output LFB ports are defined. 2355 All validated IPv4 unicast packets will be output at the singleton 2356 port known as "IPv4UnicastOut". All validated IPv4 multicast packets 2357 will be output at the singleton port known as "IPv4MulticastOut" 2358 port. 2360 A singleton port known as "ExceptionOut" is defined to output packets 2361 which have been validated as exception packets. An exception ID 2362 metadata is produced to indicate what has caused the exception. An 2363 exception case is the case when a packet needs further processing 2364 before being normally forwarded. Currently defined exception types 2365 include: 2367 o Packet with expired TTL 2369 o Packet with header length more than 5 words 2371 o Packet IP head including Router Alert options 2373 o Packet with exceptional source address 2375 o Packet with exceptional destination address 2377 Note that although TTL is checked in this LFB for validity, 2378 operations like TTL decrement are made by the downstream forwarding 2379 LFB. 2381 The final singleton port known as "FailOut" is defined for all 2382 packets which have errors and failed the validation process. An 2383 error case is the case when a packet is unable to be further 2384 processed nor forwarded except being dropped. An error ID is 2385 associated a packet to indicate the failure reason. Currently 2386 defined failure reasons include: 2388 o Packet with size reported less than 20 bytes 2390 o Packet with version is not IPv4 2392 o Packet with header length less than 5 words 2394 o Packet with total length field less than 20 bytes 2396 o Packet with invalid checksum 2398 o Packet with invalid source address 2399 o Packet with invalid destination address 2401 5.2.1.2. Components 2403 This LFB has only one struct component, the 2404 IPv4ValidatorStatisticsType, which defines a set of statistics for 2405 validation process, including the number of bad header packets, the 2406 number of bad total length packets, the number of bad TTL packets, 2407 and the number of bad checksum packets. 2409 5.2.1.3. Capabilities 2411 This LFB does not have a list of capabilities 2413 5.2.1.4. Events 2415 This LFB does not have any events specified. 2417 5.2.2. IPv6Validator 2419 The IPv6Validator LFB performs IPv6 packets validation according to 2420 [RFC2460]. 2422 5.2.2.1. Data Handling 2424 This LFB performs IPv6 validation according to [RFC2460]. Then the 2425 IPv6 packet will be output to the corresponding port regarding of the 2426 validation result, whether the packet is a unicast or a multicast 2427 one, an exception has occurred or the validation failed. 2429 This LFB always expects, as input, packets which have been indicated 2430 as IPv6 packets by an upstream LFB, like an EtherClassifier LFB. 2431 There is no specific metadata expected by the input of the LFB. 2433 Similar to the IPv4validator LFB, IPv6Validator LFB has also defined 2434 four output ports to emit packets with various validation results. 2436 All validated IPv6 unicast packets will be output at the singleton 2437 port known as "IPv6UnicastOut". All validated IPv6 multicast packets 2438 will be output at the singleton port known as "IPv6MulticastOut" 2439 port. There is no metadata produced at this LFB. 2441 A singleton port known as "ExceptionOut" is defined to output packets 2442 which have been validated as exception packets. An exception case is 2443 the case when a packet needs further processing before being normally 2444 forwarded. An exception ID metadata is produced to indicate what 2445 caused the exception. Currently defined exception types include: 2447 o Packet with hop limit to zero 2449 o Packet with next header set to Hop-by-Hop 2451 o Packet with exceptional source address 2453 o Packet with exceptional destination address 2455 The final singleton port known as "FailOut" is defined for all 2456 packets which have errors and failed the validation process. An 2457 error case is the case when a packet is unable to be further 2458 processed nor forwarded except being dropped. A validate error ID is 2459 associated to every failed packet to indicate the reason. Currently 2460 defined reasons include: 2462 o Packet with size reported less than 40 bytes 2464 o Packet with not IPv6 version 2466 o Packet with invalid source address 2468 o Packet with invalid destination address 2470 Note that in the base type library, definitions for exception ID and 2471 validate error ID metadata are applied to both IPv4Validator and 2472 IPv6Validator LFBs, i.e., the two LFBs share the same medadata 2473 definition, with different ID assignment inside. 2475 5.2.2.2. Components 2477 This LFB has only one struct component, the 2478 IPv6ValidatorStatisticsType, which defines a set of statistics for 2479 validation process, including the number of bad header packets, the 2480 number of bad total length packets, and the number of bad hop limit 2481 packets. 2483 5.2.2.3. Capabilities 2485 This LFB does not have a list of capabilities 2487 5.2.2.4. Events 2489 This LFB does not have any events specified. 2491 5.3. IP Forwarding LFBs 2493 IP Forwarding LFBs are specifically defined to abstract the IP 2494 forwarding processes. As definitions for a base LFB library, this 2495 document restricts its LFB definition scope only to IP unicast 2496 forwarding. IP multicast may be defined in future documents. 2498 A typical IP unicast forwarding job is usually realized by looking up 2499 the forwarding information table to find next hop information, and 2500 then based on the next hop information, forwarding packets to 2501 specific physical output ports. It usually takes two steps to do so, 2502 firstly to look up a forwarding information table by means of Longest 2503 Prefix Matching(LPM) rule to find a next hop index, then to use the 2504 index as a search key to look up a next hop information table to find 2505 enough information to submit packets to output ports. This document 2506 abstracts the forwarding processes mainly based on the two steps 2507 model. However, there actually exists other models, like one which 2508 may only have a forwarding information base that have conjoined next 2509 hop information together with forwarding information. In this case, 2510 if ForCES technology is to be applied, some translation work will 2511 have to be done in the FE to translate attributes defined by this 2512 document into attributes related to the implementation. 2514 Based on the IP forwarding abstraction, two kind of typical IP 2515 unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next 2516 hop application LFB. They are further distinguished by IPv4 and IPv6 2517 protocols. 2519 5.3.1. IPv4UcastLPM 2521 The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match 2522 (LPM) process. 2524 This LFB also provides facilities to support users to implement 2525 equal-cost multi-path routing (ECMP) or reverse path forwarding 2526 (RPF). However, this LFB itself does not provide ECMP or RPF. To 2527 fully implement ECMP or RPF, additional specific LFBs, like a 2528 specific ECMP LFB or an RPF LFB, will have to be defined. This work 2529 may be done in the future version of the document. 2531 5.3.1.1. Data Handling 2533 This LFB performs the IPv4 unicast LPM table looking up. It always 2534 expects as input IPv4 unicast packets from one singleton input known 2535 as "PktsIn". Then the LFB uses the destination IPv4 address of every 2536 packet as search key to look up the IPv4 prefix table and generate a 2537 hop selector as the matching result. The hop selector is passed as 2538 packet metadata to downstream LFBs, and will usually be used there as 2539 a search index to find more next hop information. 2541 Three singleton output LFB ports are defined. 2543 The first singleton output known as "NormalOut" outputs IPv4 unicast 2544 packets that succeed the LPM lookup and (got a hop selector). The 2545 hop selector is associated with the packet as a metadata. Downstream 2546 from the LPM LFB is usually a next hop application LFB, like an 2547 IPv4NextHop LFB. 2549 The second singleton output known as "ECMPOut" is defined to provide 2550 support for users wishing to implement ECMP. 2552 An ECMP flag is defined in the LPM table to enable the LFB to support 2553 ECMP. When a table entry is created with the flag set true, it 2554 indicates this table entry is for ECMP only. A packet, which has 2555 passed through this prefix lookup, will always output from "ECMPOut" 2556 output port, with the hop selector being its lookup result. The 2557 output will usually directly go to a downstream ECMP processing LFB, 2558 where the hop selector can usually further generate optimized one or 2559 multiple next hop routes by use of ECMP algorithms. 2561 A default route flag is defined in the LPM table to enable the LFB to 2562 support a default route as well as loose RPF. When this flag is set 2563 true, the table entry is identified a default route which also 2564 implies that the route is forbidden for RPF. If a user wants to 2565 implement RPF on FE, a specific RPF LFB will have to be defined. In 2566 such RPF LFB, a component can be defined as an alias of the prefix 2567 table component of this LFB as described below. 2569 The final singleton output is known as "ExceptionOut" and is defined 2570 to allow exception packets to output here, along with an ExceptionID 2571 metadata to indicate what caused the exception. Currently defined 2572 exception types include: 2574 o The packet failed the LPM lookup of the prefix table. 2576 The upstream LFB of this LFB is usually IPv4Validator LFB. If RPF is 2577 to be adopted, the upstream can be an RPF LFB, when defined. 2579 The downstream LFB is usually IPv4NextHop LFB. If ECMP is adopted, 2580 the downstream can be an ECMP LFB, when defined. 2582 5.3.1.2. Components 2584 This LFB has two components. 2586 The IPv4PrefixTable component is defined as an array component of the 2587 LFB. Each row of the array contains an IPv4 address, a Prefix 2588 length, a Hop Selector, an ECMP flag and a Default Route flag. The 2589 LFB uses the destination IPv4 address of every input packet as search 2590 key to look up this table in order extract a next hop selector. The 2591 ECMP flag is for the LFB to support ECMP. The default route flag is 2592 for the LFB to support a default route and for loose RPF. 2594 The IPv4UcastLPMStats component is a struct component which collects 2595 statistics information, including the total number of input packets 2596 received, the IPv4 packets forwarded by this LFB and the number of IP 2597 datagrams discarded due to no route found. 2599 5.3.1.3. Capabilities 2601 This LFB does not have a list of capabilities 2603 5.3.1.4. Events 2605 This LFB does not have any events specified. 2607 5.3.2. IPv4NextHop 2609 This LFB abstracts the process of selecting ipv4 next hop action. 2611 5.3.2.1. Data Handling 2613 The LFB abstracts the process of next hop information application to 2614 IPv4 packets. It receives an IPv4 packet with an associated next hop 2615 identifier (HopSelector), and uses the identifier as a table index to 2616 look up a next hop table to find an appropriate LFB output port. 2618 The LFB is expected to receive unicast IPv4 packets, via a singleton 2619 input known as "PktsIn" along with a HopSelector metadata which is 2620 used as a table index to lookup the NextHop table. The data 2621 processing involves the forwarding TTL decrement and IP checksum 2622 recalculation. 2624 Two output LFB ports are defined. 2626 The first output is a group output port known as "SuccessOut". On 2627 successful data processing the packet is sent out an LFB-port from 2628 within the LFB port group as selected by the LFBOutputSelectIndex 2629 value of the matched table entry. The packet is sent to a downstream 2630 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. 2632 The second output is a singleton output port known as "ExceptionOut", 2633 which will output packets for which the data processing failed, along 2634 with an additional ExceptionID metadata to indicate what caused the 2635 exception. Currently defined exception types include: 2637 o The HopSelector for the packet is invalid. 2639 o The packet failed lookup of the next hop table even though the 2640 HopSelector is valid. 2642 o The MTU for outgoing interface is less than the packet size. 2644 Downstream LFB instances could be either a BasicMetadataDispatch type 2645 (Section 5.5.1), used to fan out to different LFB instances or a 2646 media encapsulation related type, such as an EtherEncap type or a 2647 RedirectOut type(Section 5.4.2). For example, if there are Ethernet 2648 and other tunnel Encapsulation, then a BasicMetadataDispatch LFB can 2649 use the L3PortID metadata (Section 5.3.2.2) to dispatch packets to 2650 different encapsulator. 2652 5.3.2.2. Components 2654 This LFB has only one component named IPv4NextHopTable which is 2655 defined as an array. The HopSelector received is used to match the 2656 array index of IPv4NextHopTable to find out a row of the table as the 2657 next hop information result. Each row of the array is a struct 2658 containing: 2660 o The L3PortID, which is the ID of the Logical Output Port that is 2661 passed onto the downstream LFB instance. This ID indicates what 2662 port to the neighbor is as defined by L3. Usually this ID is used 2663 for the next hop LFB to distinguish packets that need different L2 2664 encapsulating. For instance, some packets may require general 2665 Ethernet encapsulation while others may require various types of 2666 tunnel encapsulations. In such case, different L3PortIDs are 2667 assigned to the packets and are as metadata passed to downstream 2668 LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be 2669 applied as the downstream LFB so as to dispatch packets to 2670 different encapsulation LFB instances according to the L3PortIDs. 2672 o MTU, the Maximum Transmission Unit for the outgoing port. 2674 o NextHopIPAddr, the IPv4 next hop address. 2676 o MediaEncapInfoIndex, the index we pass onto the downstream 2677 encapsulation LFB instance and that is used there as a search key 2678 to lookup a table (typically media encapsulation related) for 2679 further encapsulation information. The search key looks up the 2680 table by matching the table index.Note that an encapsulation LFB 2681 instance may not directly follow the next hop LFB, but the index 2682 is passed as a metadata associated, as such an encapsulation LFB 2683 instance even further downstream to the next hop LFB can still use 2684 the index. In some cases, depending on implementation, the CE may 2685 set the MediaEncapInfoIndex passed downstream to a value that will 2686 fail lookup when it gets to a target encapsulation LFB; such a 2687 lookup failure at that point is an indication that further 2688 resolution is needed. For an example of this approach refer to 2689 Section 7.2 which talks about ARP and mentions this approach. 2691 o LFBOutputSelectIndex, the LFB Group output port index to select 2692 downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's 2693 table LFBTopology (See [RFC5812]) component FromPortIndex 2694 corresponding to the port group mapping FromLFBID as IPv4NextHop 2695 LFB instance. 2697 5.3.2.3. Capabilities 2699 This LFB does not have a list of capabilities 2701 5.3.2.4. Events 2703 This LFB does not have any events specified. 2705 5.3.3. IPv6UcastLPM 2707 The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match 2708 (LPM) process. The definition of this LFB is similar to the 2709 IPv4UcastLPM LFB except that all IP addresses refer to IPv6 2710 addresses. 2712 This LFB also provides facilities to support users to implement 2713 equal-cost multi-path routing (ECMP) or reverse path forwarding 2714 (RPF). However, this LFB itself does not provide ECMP or RPF. To 2715 fully implement ECMP or RPF, additional specific LFBs, like a 2716 specific ECMP LFB or an RPF LFB, will have to be defined. This work 2717 may be done in the future version of the document. 2719 5.3.3.1. Data Handling 2721 This LFB performs the IPv6 unicast LPM table look up. It always 2722 expects as input IPv6 unicast packets from one singleton input known 2723 as "PktsIn". The destination IPv6 address of an incoming packet is 2724 used as search key to look up the IPv6 prefix table and generate a 2725 hop selector. This hop selector result is associated to the packet 2726 as a metadata and sent to downstream LFBs, and will usually be used 2727 in downstream LFBs as a search key to find more next hop information. 2729 Three singleton output LFB ports are defined. 2731 The first singleton output known as "NormalOut" outputs IPv6 unicast 2732 packets that succeed the LPM lookup (and got a hop selector). The 2733 hop selector is associated with the packet as a metadata. Downstream 2734 from the LPM LFB is usually a next hop application LFB, like an 2735 IPv6NextHop LFB. 2737 The second singleton output known as "ECMPOut" is defined to provide 2738 support for users wishing to implement ECMP. 2740 An ECMP flag is defined in the LPM table to enable the LFB to support 2741 ECMP. When a table entry is created with the flag set true, it 2742 indicates this table entry is for ECMP only. A packet, which has 2743 passed through this prefix lookup, will always output from "ECMPOut" 2744 output port, with the hop selector being its lookup result. The 2745 output will usually directly go to a downstream ECMP processing LFB, 2746 where the hop selector can usually further generate optimized one or 2747 multiple next hop routes by use of ECMP algorithms. 2749 A default route flag is defined in the LPM table to enable the LFB to 2750 support a default route as well as loose RPF. When this flag is set 2751 true, the table entry is identified a default route which also 2752 implies that the route is forbidden for RPF. 2754 If a user wants to implement RPF on FE, a specific RPF LFB will have 2755 to be defined. In such RPF LFB, a component can be defined as an 2756 alias of the prefix table component of this LFB as described below. 2758 The final singleton output is known as "ExceptionOut" and is defined 2759 to allow exception packets to output here, along with an ExceptionID 2760 metadata to indicate what caused the exception. Currently defined 2761 exception types include: 2763 o The packet failed the LPM lookup of the prefix table. 2765 The upstream LFB of this LFB is usually IPv6Validator LFB. If RPF is 2766 to be adopted, the upstream can be an RPF LFB, when defined. 2768 The downstream LFB is usually an IPv6NextHop LFB. If ECMP is 2769 adopted, the downstream can be an ECMP LFB, when defined. 2771 5.3.3.2. Components 2773 This LFB has two components. 2775 The IPv6PrefixTable component is defined as an array component of the 2776 LFB. Each row of the array contains an IPv6 address, a Prefix 2777 length, a Hop Selector, an ECMP flag and a Default Route flag. The 2778 ECMP flag is so the LFB can support ECMP. The default route flag is 2779 for the LFB to support a default route and for loose RPF as described 2780 earlier. 2782 The IPv6UcastLPMStats component is a struct component which collects 2783 statistics information, including the total number of input packets 2784 received, the IPv6 packets forwarded by this LFB and the number of IP 2785 datagrams discarded due to no route found. 2787 5.3.3.3. Capabilities 2789 This LFB does not have a list of capabilities 2791 5.3.3.4. Events 2793 This LFB does not have any events specified. 2795 5.3.4. IPv6NextHop 2797 This LFB abstracts the process of selecting IPv6 next hop action. 2799 5.3.4.1. Data Handling 2801 The LFB abstracts the process of next hop information application to 2802 IPv6 packets. It receives an IPv6 packet with an associated next hop 2803 identifier (HopSelector), and uses the identifier to look up a next 2804 hop table to find an appropriate output port from the LFB. 2806 The LFB is expected to receive unicast IPv6 packets, via a singleton 2807 input known as "PktsIn" along with a HopSelector metadata which is 2808 used as a table index to lookup the next hop table. 2810 Two output LFB ports are defined. 2812 The first output is a group output port known as "SuccessOut". On 2813 successful data processing the packet is sent out an LFB port from 2814 within the LFB port group as selected by the LFBOutputSelectIndex 2815 value of the matched table entry. The packet is sent to a downstream 2816 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. 2818 The second output is a singleton output port known as "ExceptionOut", 2819 which will output packets for which the data processing failed, along 2820 with an additional ExceptionID metadata to indicate what caused the 2821 exception. Currently defined exception types include: 2823 o The HopSelector for the packet is invalid. 2825 o The packet failed lookup of the next hop table even though the 2826 HopSelector is valid. 2828 o The MTU for outgoing interface is less than the packet size. 2830 Downstream LFB instances could be either a BasicMetadataDispatch 2831 type, used to fan out to different LFB instances or a media 2832 encapsulatation related type, such as an EtherEncap type or a 2833 RedirectOut type. For example, when the downstream LFB is 2834 BasicMetadataDispatch, and there exist Ethernet and other tunnel 2835 Encapsulation downstream from BasicMetadataDispatch, then the 2836 BasicMetadataDispatch LFB can use the L3PortID metadata (See section 2837 below) to dispatch packets to the different encapsulator LFBs. 2839 5.3.4.2. Components 2841 This LFB has only one component named IPv6NextHopTable which is 2842 defined as an array. The array index of IPv6NextHopTable is used for 2843 a HopSelector to find out a row of the table as the next hop 2844 information. Each row of the array is a struct containing: 2846 o The L3PortID, which is the ID of the Logical Output Port that is 2847 passed onto the downstream LFB instance. This ID indicates what 2848 port to the neighbor is as defined by L3. Usually this ID is used 2849 for the next hop LFB to distinguish packets that need different L2 2850 encapsulating. For instance, some packets may require general 2851 Ethernet encapsulation while others may require various types of 2852 tunnel encapsulations. In such case, different L3PortIDs are 2853 assigned to the packets and are as metadata passed to downstream 2854 LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be 2855 applied as the downstream LFB so as to dispatch packets to 2856 different encapsulation LFB instances according to the L3PortIDs. 2858 o MTU, the Maximum Transmission Unit for the outgoing port. 2860 o NextHopIPAddr, the IPv6 next hop address. 2862 o MediaEncapInfoIndex, the index we pass onto the downstream 2863 encapsulation LFB instance and that is used there as a search key 2864 to lookup a table (typically media encapsulation related) for 2865 further encapsulation information. The saearch key looks up the 2866 table by matching the table index. Note that an encapsulation LFB 2867 instance may not directly follow the next hop LFB, but the index 2868 is passed as a metadata associated, as such an encapsulation LFB 2869 instance even further downstream to the next hop LFB can still use 2870 the index. In some cases, depending on implementation, the CE may 2871 set the MediaEncapInfoIndex passed downstream to a value that will 2872 fail lookup when it gets to a target encapsulation LFB; such a 2873 lookup failure at that point is an indication that further 2874 resolution is needed. For an example of this approach refer to 2875 Section 7.2 which talks about ARP and mentions this approach. 2877 o LFBOutputSelectIndex, the LFB Group output port index to select 2878 downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's 2879 table LFBTopology (See [RFC5812]) component FromPortIndex 2880 corresponding to the port group mapping FromLFBID as IPv4NextHop 2881 LFB instance. 2883 5.3.4.3. Capabilities 2885 This LFB does not have a list of capabilities 2887 5.3.4.4. Events 2889 This LFB does not have any events specified. 2891 5.4. Redirect LFBs 2893 Redirect LFBs abstract data packets transportation process between CE 2894 and FE. Some packets output from some LFBs may have to be delivered 2895 to CE for further processing, and some packets generated by CE may 2896 have to be delivered to FE and further to some specific LFBs for data 2897 path processing. According to [RFC5810], data packets and their 2898 associated metadata are encapsulated in ForCES redirect message for 2899 transportation between CE and FE. We define two LFBs to abstract the 2900 process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an LFB 2901 topology of an FE, only one RedirectIn LFB instance and one 2902 RedirectOut LFB instance exist. 2904 5.4.1. RedirectIn 2906 RedirectIn LFB abstracts the process for the CE to inject data 2907 packets into the FE data path. 2909 5.4.1.1. Data Handling 2911 A RedirectIn LFB abstracts the process for the CE to inject data 2912 packets into the FE LFB topology so as to input data packets into FE 2913 data paths. From LFB topology point of view, the RedirectIn LFB acts 2914 as a source point for data packets coming from CE, therefore 2915 RedirectIn LFB is defined with a single output LFB port (and no input 2916 LFB port). 2918 The single output port of RedirectIn LFB is defined as a group output 2919 type, with the name of "PktsOut". Packets produced by this output 2920 will have arbitrary frame types decided by the CE which generated the 2921 packets. Possible frames may include IPv4, IPv6, or ARP protocol 2922 packets. The CE may associate some metadata to indicate the frame 2923 types and may also associate other metadata to indicate various 2924 information on the packets. Among them, there MUST exist a 2925 'RedirectIndex' metadata, which is an integer acting as an index. 2926 When the CE transmits the metadata along with the packet to a 2927 RedirectIn LFB, the LFB will read the RedirectIndex metadata and 2928 output the packet to one of its group output port instance, whose 2929 port index is indicated by this metadata. Any other metadata, in 2930 addition to 'RedirectIndex', will be passed untouched along the 2931 packet delivered by the CE to downstream LFB. This means the 2932 'RedirectIndex' metadata from CE will be "consumed" by the RedirectIn 2933 LFB and will not be passed to downstream LFB. Note that, a packet 2934 from CE without a 'RedirectIndex' metadata associated will be dropped 2935 by the LFB. 2937 5.4.1.2. Components 2939 There are no components defined for the current version of RedirectIn 2940 LFB. 2942 5.4.1.3. Capabilities 2944 This LFB does not have a list of capabilities 2946 5.4.1.4. Events 2948 This LFB does not have any events specified. 2950 5.4.2. RedirectOut 2952 RedirectOut LFB abstracts the process for LFBs in the FE to deliver 2953 data packets to the CE. 2955 5.4.2.1. Data Handling 2957 A RedirectOut LFB abstracts the process for LFBs in the FE to deliver 2958 data packets to the CE. From the LFB's topology point of view, the 2959 RedirectOut LFB acts as a sink point for data packets going to the 2960 CE, therefore RedirectOut LFB is defined with a single input LFB port 2961 (and no output LFB port). 2963 The RedirectOut LFB has only one singleton input known as "PktsIn", 2964 but is capable of receiving packets from multiple LFBs by 2965 multiplexing this input. The input expects any kind of frame type 2966 therefore the frame type has been specified as arbitrary, and also 2967 all types of metadata are expected. All associated metadata produced 2968 (but not consumed) by previous processed LFBs should be delivered to 2969 CE via the ForCES protocol redirect message [RFC5810]. The CE can 2970 decide on how to process the redirected packet by referencing the 2971 associated metadata. As an example, a packet could be redirected by 2972 the FE to the CE because the EtherEncap LFB is not able to resolve L2 2973 information. The metadata "ExceptionID", created by the EtherEncap 2974 LFB is passed along with the packet and should be sufficient for the 2975 CE to do the necessary processing and resolve the L2 entry required. 2977 5.4.2.2. Components 2979 There are no components defined for the current version of 2980 RedirectOut LFB. 2982 5.4.2.3. Capabilities 2984 This LFB does not have a list of capabilities 2986 5.4.2.4. Events 2988 This LFB does not have any events specified. 2990 5.5. General Purpose LFBs 2992 5.5.1. BasicMetadataDispatch 2994 The BasicMetadataDispatch LFB is defined to abstract the process in 2995 which a packet is dispatched to some output path based on its 2996 associated metadata value. 2998 5.5.1.1. Data Handling 3000 The BasicMetadataDispatch has only one singleton input known as 3001 "PktsIn". Every input packet should be associated with a metadata 3002 that will be used by the LFB to do the dispatch. This LFB contains a 3003 metadata ID and a dispatch table named MetadataDispatchTable, all 3004 configured by the CE. The metadata ID specifies which metadata is to 3005 be used for dispatching packets. The MetadataDispatchTable contains 3006 entries of a metadata value and an OutputIndex, specifying that the 3007 packet with the metadata value must go out from the LFB group output 3008 port instance with the OutputIndex. 3010 Two output LFB ports are defined. 3012 The first output is a group output port known as "PktsOut". A packet 3013 with its associated metadata having found an OutputIndex by 3014 successfully looking up the dispatch table will be output to the 3015 group port instance with the corresponding index. 3017 The second output is a singleton output port known as "ExceptionOut", 3018 which will output packets for which the data processing failed, along 3019 with an additional ExceptionID metadata to indicate what caused the 3020 exception. Currently defined exception types include: 3022 o There is no matching when looking up the metadata dispatch table. 3024 As an example, if the CE decides to dispatch packets according to a 3025 physical port ID (PHYPortID), the CE may set the ID of PHYPortID 3026 metadata to the LFB first. Moreover, the CE also sets the PHYPortID 3027 actual values (the metadata values) and assigned OutputIndex for the 3028 values to the dispatch table in the LFB. When a packet arrives, a 3029 PHYPortID metadata is found associated with the packet, the metadata 3030 value is further used as a key to look up the dispatch table to find 3031 out an output port instance for the packet. 3033 Currently the BasicMetadataDispatch LFB only allows the metadata 3034 value of the dispatch table entry be 32-bits integer. A metadata 3035 with other types of value is not supported in this version. A more 3036 complex metadata dispatch LFB may be defined in future version of the 3037 library. In that LFB, multiple tuples of metadata with more value 3038 types supported may be used to dispatch packets. 3040 5.5.1.2. Components 3042 This LFB has two components. One component is MetadataID and the 3043 other is MetadataDispatchTable. Each row entry of the dispatch table 3044 is a struct containing metadata value and the OutputIndex. Note that 3045 currently, the metadata value is only allowed to be 32-bits integer. 3046 The metadata value is also defined as a content key for the table. 3047 The concept of content key is a searching key for tables which is 3048 defined in the ForCES FE Model [RFC5812]. With the content key, CE 3049 can manipulate the table by means of a specific metadata value rather 3050 than by the table index only. See [RFC5812] document and also the 3051 ForCES Protocol [RFC5810] for more details on the definition and use 3052 of a content key. 3054 5.5.1.3. Capabilities 3056 This LFB does not have a list of capabilities 3058 5.5.1.4. Events 3060 This LFB does not have any events specified. 3062 5.5.2. GenericScheduler 3064 This is a preliminary generic scheduler LFB for abstracting a simple 3065 scheduling process. 3067 5.5.2.1. Data Handling 3069 There exist various kinds of scheduling strategies with various 3070 implementations. As a base LFB library, this document only defines a 3071 preliminary generic scheduler LFB for abstracting a simple scheduling 3072 process. Users may use this LFB as a basic scheduler LFB to further 3073 construct more complex scheduler LFBs by means of inheritance as 3074 described in [RFC5812]. 3076 Packets of any arbitrary frame type are received via a group input 3077 known as "PktsIn" with no additional metadata expected. This group 3078 input is capable of multiple input port instances. Each port 3079 instance may be connected to different upstream LFB output. Inside 3080 the LFB, it is abstracted that each input port instance is connected 3081 to a queue, and the queue is marked with a queue ID whose value is 3082 exactly the same as the index of corresponding group input port 3083 instance. Scheduling disciplines are applied to all queues and also 3084 all packets in the queues.The group input port property 3085 PortGroupLimits in ObjectLFB as defined by ForCES FE model[RFC5810] 3086 provides means for the CE to query the capability of total queue 3087 numbers the scheduler supports. The CE can then decide how many 3088 queues it may use for a scheduling application. 3090 Scheduled packets are output from a singleton output port of the LFB 3091 knows as "PktsOut" with no corresponding metadata. 3093 More complex scheduler LFBs may be defined with more complex 3094 scheduling disciplines by succeeding this LFB. For instance, a 3095 priority scheduler LFB may be defined by inheriting this LFB and 3096 defining a component to indicate priorities for all input queues. 3098 5.5.2.2. Components 3100 The SchedulingDiscipline component is for the CE to specify a 3101 scheduling discipline to the LFB. Currently defined scheduling 3102 disciplines only include Round Robin (RR) strategy. The default 3103 scheduling discipline is RR then. 3105 The QueueStats component is defined to allow CE to query every queue 3106 status of the scheduler. It is an array component and each row of 3107 the array is a struct containing a queue ID. Currently defined queue 3108 status includes the queue depth in packets and the queue depth in 3109 bytes. Using the queue ID as the index, the CE can query every queue 3110 for its used length in unit of packets or bytes. 3112 5.5.2.3. Capabilities 3114 The following capability is currently defined for the 3115 GenericScheduler. 3117 o The queue length limit providing the storage ability for every 3118 queue. 3120 5.5.2.4. Events 3122 This LFB does not have any events specified. 3124 6. XML for LFB Library 3126 3127 3130 3131 3132 3133 EtherPHYCop 3134 3135 The EtherPHYCop LFB describes an Ethernet interface 3136 abstracted at physical layer. It limits the physical media 3137 to copper. 3138 3139 1.0 3140 3141 3142 EtherPHYIn 3143 3144 The input port of the EtherPHYCop LFB. It expects any 3145 type of Ethernet frame. 3146 3147 3148 3149 EthernetAll 3150 3151 3152 3153 3154 3155 3156 EtherPHYOut 3157 3158 The output port of the EtherPHYCop LFB. The output 3159 packet has the same Ethernet frame type with the 3160 input packet, associated with a metadata indicating 3161 the ID of the physical port. 3162 3163 3164 3165 EthernetAll 3166 3167 3168 PHYPortID 3169 3170 3172 3173 3174 3175 3176 PHYPortID 3177 3178 The identification of the physical port 3179 3180 uint32 3181 3182 3183 AdminStatus 3184 3185 The port status administratively requested 3186 3187 PortStatusType 3188 2 3189 3190 3191 OperStatus 3192 3193 The actual operational status of the port 3194 3195 PortStatusType 3196 3197 3198 AdminLinkSpeed 3199 3200 The port link speed administratively requested 3201 3202 LANSpeedType 3203 LAN_SPEED_AUTO 3204 3205 3206 OperLinkSpeed 3207 3208 The actual operational link speed of the port 3209 3210 LANSpeedType 3211 3212 3213 AdminDuplexMode 3214 3215 The port duplex mode administratively requested 3216 3217 DuplexType 3218 Auto 3219 3220 3221 OperDuplexMode 3222 3223 The actual operational duplex mode of the port 3224 3225 DuplexType 3226 3227 3228 CarrierStatus 3229 The carrier status of the port 3230 boolean 3231 false 3232 3233 3234 3235 3236 SupportedLinkSpeed 3237 3238 A list of link speeds the port supports 3239 3240 3241 LANSpeedType 3242 3243 3244 3245 SupportedDuplexMode 3246 3247 A list of duplex modes the port supports 3248 3249 3250 DuplexType 3251 3252 3253 3254 3255 3256 PHYPortStatusChanged 3257 3258 An event reports change on operational status of the 3259 physical port. 3260 3261 3262 OperStatus 3263 3264 3265 3266 3267 OperStatus 3269 3270 3271 3272 3273 LinkSpeedChanged 3274 3275 An event reports change on operational link speed of 3276 the physical port. 3277 3278 3279 OperLinkSpeed 3280 3281 3282 3283 3284 OperLinkSpeed 3285 3286 3287 3288 3289 DuplexModeChanged 3290 3291 An event reports change on operational duplex mode of 3292 the physical port. 3293 3294 3295 OperDuplexMode 3296 3297 3298 3299 3300 OperDuplexMode 3301 3302 3303 3304 3305 3306 3307 EtherMACIn 3308 3309 EtherMACIn LFB abstracts an Ethernet port at MAC data link 3310 layer. This LFB describes Ethernet processing functions 3311 like MAC address locality check, deciding if the Ethernet 3312 packets should be bridged, providing Ethernet layer flow 3313 control, etc. 3314 3315 1.0 3316 3317 3318 EtherPktsIn 3319 3320 The input port of the EtherMACIn LFB. It expects any 3321 type of Ethernet frame. 3322 3323 3324 3325 EthernetAll 3326 3327 3328 PHYPortID 3329 3330 3331 3332 3333 3334 3335 NormalPathOut 3336 3337 An output port called normal path output in the 3338 EtherMACIn LFB. It outputs Ethernet packets to 3339 downstream LFBs for normal processing like Ethernet 3340 packet classification and further L3 processing. 3341 3342 3343 3344 EthernetAll 3345 3346 3347 PHYPortID 3348 3349 3350 3351 3352 L2BridgingPathOut 3353 3354 An output port called L2 bridging path output in 3355 the EtherMACIn LFB. It outputs Ethernet packets 3356 to downstream LFBs for layer 2 bridging processing. 3357 The port is switched on or off by the 3358 L2BridgingPathEnable flag. 3359 3360 3361 3362 EthernetAll 3363 3364 3365 PHYPortID 3366 3367 3368 3369 3370 3371 3372 AdminStatus 3373 3374 The LFB status administratively requested, which has 3375 the same data type with a port status. Default is in 3376 'down' status. 3377 3378 PortStatusType 3379 2 3380 3381 3382 LocalMACAddresses 3383 3384 Local MAC addresses of the Ethernet port the LFB 3385 represents. 3386 3387 3388 IEEEMAC 3389 3390 3391 3392 L2BridgingPathEnable 3393 3394 A flag indicating if the LFB L2 BridgingPath output 3395 port is enabled or not. Default is not. 3396 3397 boolean 3398 false 3399 3400 3401 PromiscuousMode 3402 3403 A flag indicating whether the LFB is in promiscuous 3404 mode or not. Default is not. 3405 3406 boolean 3407 false 3408 3409 3410 TxFlowControl 3411 3412 A flag indicating whether transmit flow control is 3413 applied or not. Default is not. 3414 3415 boolean 3416 false 3417 3418 3419 RxFlowControl 3420 3421 A flag indicating whether receive flow control is 3422 applied or not. Default is not. 3423 3424 boolean 3425 false 3426 3427 3428 MACInStats 3429 3430 The statistics of the EtherMACIn LFB 3431 3432 MACInStatsType 3433 3434 3435 3436 3437 EtherClassifier 3438 3439 EtherClassifier LFB abstracts the process to decapsulate 3440 Ethernet packets and then classifies them into various 3441 network layer packets according to information in the 3442 Ethernet headers. It is expected the LFB classifies packets 3443 by packet types like IPv4, IPv6, MPLS, ARP, ND, etc. 3444 3445 1.0 3446 3447 3448 EtherPktsIn 3449 3450 Input port of Ethernet packets. A PHYPortID metadata 3451 is associated and a LogicalPortID metadata is 3452 optionally associated with every packet. 3453 3454 3455 3456 EthernetAll 3457 3458 3459 PHYPortID 3460 3462 LogicalPortID 3463 3464 3465 3466 3467 3468 3469 ClassifyOut 3470 3471 A group port for output of Ethernet classifying 3472 results. 3473 3474 3475 3476 Arbitrary 3477 3478 3479 PHYPortID 3480 SrcMAC 3481 DstMAC 3482 EtherType 3483 VlanID 3484 VlanPriority 3485 3486 3487 3488 3489 ExceptionOut 3490 3491 A single port for output of all Ethernet packets that 3492 fail the classifying process. An ExceptionID metadata 3493 indicates the failure reason. 3494 3495 3496 3497 Arbitrary 3498 3499 3500 ExceptionID 3501 3502 3503 3504 3505 3506 3507 EtherDispatchTable 3508 3509 An EtherDispatchTable array component is defined in 3510 the LFB to dispatch every Ethernet packet to output 3511 group according to logical port ID assigned by the 3512 VlanInputTable and Ethernet type in the Ethernet 3513 packet header. 3514 3515 EtherDispatchTableType 3516 3517 3518 VlanInputTable 3519 3520 A VlanInputTable array component is defined in the 3521 LFB to classify VLAN Ethernet packets. Every input 3522 packet is assigned with a new LogicalPortID according 3523 to the packet incoming port ID and the VLAN ID. 3524 3525 VlanInputTableType 3526 3527 3528 EtherClassifyStats 3529 3530 A table records statistics on the Ethernet 3531 classifying process in the LFB. 3532 3533 EtherClassifyStatsTableType 3534 3535 3536 3537 3538 EtherEncap 3539 3540 This LFB abstracts the process of encapsulating Ethernet 3541 headers onto received packets. The encapsulation is based 3542 on passed metadata. 3543 3544 1.0 3545 3546 3547 EncapIn 3548 3549 A port inputs IPv4 and/or IPv6 packets for 3550 encapsulation. A MediaEncapInfoIndex metadata is 3551 expected and a VLAN priority metadata is optionally 3552 expected with every input packet. 3553 3554 3555 3556 IPv4 3557 IPv6 3559 3560 3561 MediaEncapInfoIndex 3562 3563 VlanPriority 3564 3565 3566 3567 3568 3569 3570 SuccessOut 3571 3572 Output port for packets which have found Ethernet L2 3573 information and have been successfully encapsulated 3574 into an Ethernet packet. An L2portID metadata is 3575 produced for every packet. 3576 3577 3578 3579 IPv4 3580 IPv6 3581 3582 3583 L2PortID 3584 3585 3586 3587 3588 ExceptionOut 3589 3590 Output port for all packets that fail encapsulation 3591 in the LFB. An ExceptionID metadata indicates failure 3592 reason. 3593 3594 3595 3596 IPv4 3597 IPv6 3598 3599 3600 ExceptionID 3601 MediaEncapInfoIndex 3602 VlanPriority 3603 3604 3605 3606 3607 3608 3609 EncapTable 3610 3611 An array for Ethernet encapsulation information 3612 lookup.Each row of the array contains destination MAC 3613 address, source MAC address, VLAN ID, and output 3614 logical L2 port ID. 3615 3616 EncapTableType 3617 3618 3619 3620 3621 EtherMACOut 3622 3623 EtherMACOut LFB abstracts an Ethernet port at MAC data link 3624 layer. It specifically describes Ethernet packet process 3625 for output to physical port. A downstream LFB is usually an 3626 Ethernet physical LFB like EtherPHYcop LFB.Ethernet output 3627 functions are closely related to Ethernet input functions, 3628 therefore some components defined in this LFB are as alias 3629 of EtherMACIn LFB. 3630 3631 1.0 3632 3633 3634 EtherPktsIn 3635 3636 The input port of the EtherMACOut LFB. It expects any 3637 type of Ethernet frame. 3638 3639 3640 3641 EthernetAll 3642 3643 3644 PHYPortID 3645 3646 3647 3648 3649 3650 3651 EtherPktsOut 3652 3653 A port to output all Ethernet packets,each with a 3654 metadata indicating the physical port ID the packet 3655 is to go through. 3656 3657 3658 3659 EthernetAll 3660 3661 3662 PHYPortID 3663 3664 3665 3666 3667 3668 3669 AdminStatus 3670 3671 The LFB status administratively requested, which has 3672 the same data type with a port status. It is defined 3673 as alias of AdminStatus component in EtherMACIn LFB. 3674 3675 PortStatusType 3676 3677 3678 MTU 3679 Maximum transmission unit (MTU) 3680 uint32 3681 3682 3683 TxFlowControl 3684 3685 A flag indicating whether transmit flow control is 3686 applied, defined as alias of TxFlowControl component 3687 in EtherMACIn LFB. 3688 3689 boolean 3690 3691 3692 RxFlowControl 3693 3694 A flag indicating whether receive flow control is 3695 applied, defined as alias of RxFlowControl component 3696 in EtherMACIn LFB. 3697 3698 boolean 3699 3700 3701 MACOutStats 3702 3703 The statistics of the EtherMACOut LFB 3704 3705 MACOutStatsType 3706 3707 3708 3709 3710 IPv4Validator 3711 3712 The IPv4Validator LFB performs IPv4 validation according to 3713 [RFC5812]. The IPv4 packet will be output to the 3714 corresponding port regarding of the validation result, 3715 whether the packet is unicast, multicast or whether an 3716 exception has occurred or the validation failed. 3717 3718 1.0 3719 3720 3721 ValidatePktsIn 3722 3723 Input port for data packets to be validated 3724 3725 3726 3727 Arbitrary 3728 3729 3730 3731 3732 3733 3734 IPv4UnicastOut 3735 3736 Output port for validated IPv4 unicast packets 3737 3738 3739 3740 IPv4Unicast 3741 3742 3743 3744 3745 IPv4MulticastOut 3746 3747 Output port for validated IPv4 multicast packets 3748 3749 3750 3751 IPv4Multicast 3752 3753 3754 3755 3756 ExceptionOut 3757 3758 Output port for all packets with exceptional cases 3759 when validating. An ExceptionID metadata indicates 3760 the exception case type. 3761 3762 3763 3764 IPv4 3765 3766 3767 ExceptionID 3768 3769 3770 3771 3772 FailOut 3773 3774 Output port for packets failed validating process. 3775 A ValidateErrorID metadata indicates the error type 3776 or failure reason. 3777 3778 3779 3780 IPv4 3781 3782 3783 ValidateErrorID 3784 3785 3786 3787 3788 3789 3790 IPv4ValidatorStats 3791 3792 The statistics information for validating process in 3793 the LFB. 3794 3795 IPv4ValidatorStatsType 3796 3797 3798 3800 3801 IPv6Validator 3802 3803 The IPv6Validator LFB performs IPv6 validation according to 3804 [RFC2460]. The IPv6 packet will be output to the 3805 corresponding port regarding of the validation result, 3806 whether the packet is a unicast or a multicast one, an 3807 exception has occurred or the validation failed. 3808 3809 1.0 3810 3811 3812 ValidatePktsIn 3813 3814 Input port for data packets to be validated 3815 3816 3817 3818 Arbitrary 3819 3820 3821 3822 3823 3824 3825 IPv6UnicastOut 3826 3827 Output port for validated IPv6 unicast packets 3828 3829 3830 3831 IPv6Unicast 3832 3833 3834 3835 3836 IPv6MulticastOut 3837 3838 Output port for validated IPv6 multicast packets 3839 3840 3841 3842 IPv6Multicast 3843 3844 3845 3846 3847 ExceptionOut 3848 3849 Output port for packets with exceptional cases when 3850 validating. An ExceptionID metadata indicates the 3851 exception case type. 3852 3853 3854 3855 IPv6 3856 3857 3858 ExceptionID 3859 3860 3861 3862 3863 FailOut 3864 3865 Output port for packets failed validating process. 3866 A ValidateErrorID metadata indicates the error type 3867 or failure reason. 3868 3869 3870 3871 IPv6 3872 3873 3874 ValidateErrorID 3875 3876 3877 3878 3879 3880 3881 IPv6ValidatorStats 3882 3883 The statistics information for validating process in 3884 the LFB. 3885 3886 IPv6ValidatorStatsType 3887 3888 3889 3890 3891 IPv4UcastLPM 3892 3893 The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest 3894 Prefix Match (LPM) process. This LFB also provides 3895 facilities to support users to implement equal-cost 3896 multi-path routing (ECMP) or reverse path forwarding (RPF). 3897 However, this LFB itself does not provide ECMP or RPF. 3898 3899 1.0 3900 3901 3902 PktsIn 3903 3904 A port for input of packets to be processed. IPv4 3905 unicast packets are expected. 3906 3907 3908 3909 IPv4Unicast 3910 3911 3912 3913 3914 3915 3916 NormalOut 3917 3918 A normal output port outputs IPv4 unicast packets 3919 that succeed the LPM lookup. A HopSelector metadata 3920 is produced for every packet for downstream LFB to 3921 do next hop action. 3922 3923 3924 3925 IPv4Unicast 3926 3927 3928 HopSelector 3929 3930 3931 3932 3933 ECMPOut 3934 3935 The port outputs packets that need further ECMP 3936 processing. An ECMP processing LFB is usually 3937 followed the output. If ECMP is not required, no 3938 downstream LFB may be connected to the port. 3939 3940 3941 3942 IPv4Unicast 3943 3944 3945 HopSelector 3946 3947 3948 3949 3950 ExceptionOut 3951 3952 The port outputs all packets with exceptional cases 3953 when doing LPM process. An ExceptionID metadata 3954 associated indicates what caused the exception. 3955 3956 3957 3958 IPv4Unicast 3959 3960 3961 ExceptionID 3962 3963 3964 3965 3966 3967 3968 IPv4PrefixTable 3969 3970 A table for IPv4 longest prefix match. The 3971 destination IPv4 address of every input packet is 3972 used as a search key to look up the table to find 3973 out a next hop selector. 3974 3975 IPv4PrefixTableType 3976 3977 3978 IPv4UcastLPMStats 3979 3980 The statistics information for IPv4 unicast longest 3981 prefix match process in the LFB. 3982 3983 IPv4UcastLPMStatsType 3984 3985 3986 3987 3988 IPv6UcastLPM 3989 3990 The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest 3991 Prefix Match (LPM) process. This LFB also provides 3992 facilities to support users to implement equal-cost 3993 multi-path routing (ECMP) or reverse path forwarding (RPF). 3994 However, this LFB itself does not provide ECMP or RPF. 3995 3996 1.0 3997 3998 3999 PktsIn 4000 4001 A port for input of packets to be processed. IPv6 4002 unicast packets are expected. 4003 4004 4005 4006 IPv6Unicast 4007 4008 4009 4010 4011 4012 4013 NormalOut 4014 4015 A normal output port outputs IPv6 unicast packets 4016 that succeed the LPM lookup. A HopSelector metadata 4017 is produced for every packet for downstream LFB to do 4018 next hop action. 4019 4020 4021 4022 IPv6Unicast 4023 4024 4025 HopSelector 4026 4027 4028 4029 4030 ECMPOut 4031 4032 The port outputs packets that need further ECMP 4033 processing. An ECMP processing LFB is usually 4034 followed the output. If ECMP is not required, no 4035 downstream LFB may be connected to the port. 4036 4037 4038 4039 IPv6Unicast 4041 4042 4043 HopSelector 4044 4045 4046 4047 4048 ExceptionOut 4049 4050 The port outputs all packets with exceptional cases 4051 when doing LPM process. An ExceptionID metadata 4052 associated indicates what caused the exception. 4053 4054 4055 4056 IPv6Unicast 4057 4058 4059 ExceptionID 4060 4061 4062 4063 4064 4065 4066 IPv6PrefixTable 4067 4068 A table for IPv6 longest prefix match. The 4069 destination IPv6 address of every input packet is 4070 used as a search key to look up the table to find 4071 out a next hop selector. 4072 4073 IPv6PrefixTableType 4074 4075 4076 IPv6UcastLPMStats 4077 4078 The statistics information for IPv6 unicast longest 4079 prefix match process in the LFB. 4080 4081 IPv6UcastLPMStatsType 4082 4083 4084 4085 4086 IPv4NextHop 4087 4088 The LFB abstracts the process of next hop information 4089 application to IPv4 packets. It receives an IPv4 packet 4090 with an associated next hop identifier (HopSelector), and 4091 uses the identifier as a table index to look up a next hop 4092 table to find an appropriate LFB output port. The data 4093 processing also involves the forwarding TTL decrement and 4094 IP checksum recalculation. 4095 4096 1.0 4097 4098 4099 PktsIn 4100 4101 A port for input of unicast IPv4 packets, along with 4102 a HopSelector metadata which is used as a table index 4103 to lookup the next hop table in the LFB. 4104 4105 4106 4107 IPv4Unicast 4108 4109 4110 HopSelector 4111 4112 4113 4114 4115 4116 4117 SuccessOut 4118 4119 The group output port for packets successfully found 4120 next hop information. The group output port index for 4121 every packet is decided by the LFBOutputSelectIndex 4122 value assigned in the next hop table entry. The 4123 packet is sent to a downstream LFB along with an 4124 L3PortID, a NextHopIPv4Addr, and optionally a 4125 MediaEncapInfoIndex metadata. 4126 4127 4128 4129 IPv4Unicast 4130 4131 4132 L3PortID 4133 NextHopIPv4Addr 4134 4135 MediaEncapInfoIndex 4136 4138 4139 4140 4141 ExceptionOut 4142 4143 The output port for packets with exceptional or 4144 failure cases when doing next hop action. An 4145 ExceptionID metadata indicates what caused the case. 4146 4147 4148 4149 IPv4Unicast 4150 4151 4152 ExceptionID 4153 4154 4155 4156 4157 4158 4159 IPv4NextHopTable 4160 4161 The IPv4NextHopTable is defined as an array. A 4162 HopSelector is used to match the array index of the 4163 table to find out a row of the table as the next hop 4164 information result. Each row of the array is a struct 4165 containing the L3PortID, MTU, NextHopIPAddr(IPv4 4166 type), MediaEncapInfoIndex, and LFBOutputSelectIndex. 4167 4168 IPv4NextHopTableType 4169 4170 4171 4172 4173 IPv6NextHop 4174 4175 The LFB abstracts the process of next hop information 4176 application to IPv6 packets. It receives an IPv6 packet 4177 with an associated next hop identifier (HopSelector), and 4178 uses the identifier as a table index to look up a next hop 4179 table to find an appropriate LFB output port. 4180 4181 1.0 4182 4183 4184 PktsIn 4185 4186 A port for input of unicast IPv6 packets, along with 4187 a HopSelector metadata which is used as a table index 4188 to lookup the next hop table in the LFB. 4189 4190 4191 4192 IPv6Unicast 4193 4194 4195 HopSelector 4196 4197 4198 4199 4200 4201 4202 SuccessOut 4203 4204 The group output port for packets successfully found 4205 next hop information. The group output port index for 4206 every packet is decided by the LFBOutputSelectIndex 4207 value assigned in the next hop table entry. The 4208 packet is sent to a downstream LFB along with an 4209 L3PortID, a NextHopIPv6Addr, and optionally a 4210 MediaEncapInfoIndex metadata. 4211 4212 4213 4214 IPv6Unicast 4215 4216 4217 L3PortID 4218 NextHopIPv6Addr 4219 4220 MediaEncapInfoIndex 4221 4222 4223 4224 4225 ExceptionOut 4226 4227 The output port for packets with exceptional or 4228 failure cases when doing next hop action. An 4229 ExceptionID metadata indicates what caused the case. 4230 4231 4232 4233 IPv6Unicast 4235 4236 4237 ExceptionID 4238 4239 4240 4241 4242 4243 4244 IPv6NextHopTable 4245 4246 The IPv6NextHopTable is defined as an array. A 4247 HopSelector is used to match the array index of the 4248 table to find out a row of the table as the next hop 4249 information result. Each row of the array is a struct 4250 containing the L3PortID, MTU, NextHopIPAddr(IPv6 4251 type), MediaEncapInfoIndex, and LFBOutputSelectIndex. 4252 4253 IPv6NextHopTableType 4254 4255 4256 4257 4258 RedirectIn 4259 4260 A RedirectIn LFB abstracts the process for the ForCES CE to 4261 inject data packets into the ForCES FE LFB topology so as to 4262 input data packets into FE data paths. 4263 4264 1.0 4265 4266 4267 PktsOut 4268 4269 The output port of RedirectIn LFB is defined as a 4270 group output type. Packets produced by this output 4271 will have arbitrary frame types decided by the CE 4272 which generated the packets. From LFB topology point 4273 of view, the RedirectIn LFB acts as a source point 4274 for data packets coming from CE, therefore RedirectIn 4275 LFB is defined with a single output LFB port (and no 4276 input LFB port). The CE may associate some metadata 4277 to indicate the frame types and may also associate 4278 other metadata to indicate information on the packets. 4279 Among them, there must exist a 'RedirectIndex' 4280 metadata, which is an integer acting as an index. When 4281 the CE transmits the metadata along with the packet to 4282 a RedirectIn LFB, the LFB will read the RedirectIndex 4283 metadata and output the packet to one of its group 4284 output port instance, whose port index is indicated 4285 by this metadata. Any other metadata, in addition to 4286 'RedirectIndex', will be passed untouched along the 4287 packet delivered by the CE to downstream LFB. This 4288 means the 'RedirectIndex' metadata from CE will be 4289 "consumed" by the RedirectIn LFB and will not be 4290 passed to downstream LFB. Note that, a packet from 4291 CE without a 'RedirectIndex' metadata associated will 4292 be dropped by the LFB. 4293 4294 4295 4296 Arbitrary 4297 4298 4299 4300 4301 4302 4303 RedirectOut 4304 4305 A RedirectOut LFB abstracts the process for LFBs in the 4306 ForCES FE to deliver data packets to the ForCES CE. 4307 4308 1.0 4309 4310 4311 PktsIn 4312 4313 The input port for the RedirectOut LFB. From the LFB's 4314 topology point of view, the RedirectOut LFB acts as a 4315 sink point for data packets going to the CE, therefore 4316 RedirectOut LFB is defined with a single input LFB 4317 port (and no output LFB port). The port expects all 4318 types of packet frames and metadata. All associated 4319 metadata produced (but not consumed) by previous 4320 processed LFBs should be delivered to the CE. 4321 4322 4323 4324 Arbitrary 4325 4326 4327 4328 4329 4330 4331 BasicMetadataDispatch 4332 4333 The BasicMetadataDispatch LFB is defined to abstract the 4334 process in which a packet is dispatched to some output path 4335 based on its associated metadata value. Current version of 4336 the LFB only allows the metadata value be 32-bits integer. 4337 4338 1.0 4339 4340 4341 PktsIn 4342 4343 The packet input port for dispatching. Every input 4344 packet should be associated with a metadata that will 4345 be used by the LFB to do the dispatch. 4346 4347 4348 4349 Arbitrary 4350 4351 4352 Arbitrary 4353 4354 4355 4356 4357 4358 4359 PktsOut 4360 4361 The group output port outputs dispatching results. A 4362 packet with its associated metadata having found an 4363 OutputIndex by successfully looking up the dispatch 4364 table will be output to the group port instance with 4365 the corresponding index. 4366 4367 4368 4369 Arbitrary 4370 4371 4372 4373 4374 ExceptionOut 4375 4376 The output port outputs packets for which the data 4377 processing failed, along with an additional 4378 ExceptionID metadata to indicate what caused the 4379 exception. 4380 4381 4382 4383 Arbitrary 4384 4385 4386 ExceptionID 4387 4388 4389 4390 4391 4392 4393 MetadataID 4394 4395 The metadata ID specifies which metadata is to be 4396 used for dispatching packets. It is configured by 4397 the CE. 4398 4399 uint32 4400 4401 4402 MetadataDispatchTable 4403 4404 The MetadataDispatchTable contains entries of a 4405 Metadata value and an OutputIndex, specifying that 4406 packet with the metadata value must go out from the 4407 LFB group output port instance with the OutputIndex. 4408 Note that in current version, the metadata value is 4409 only allowed to be 32-bits integer. The metadata value 4410 is also defined as a content key for the table. 4411 4412 MetadataDispatchTableType 4413 4414 4415 4416 4417 GenericScheduler 4418 4419 This is a preliminary generic scheduler LFB for abstracting 4420 a simple scheduling process. Users may use this LFB as a 4421 basic scheduler LFB to further construct more complex 4422 scheduler LFBs by means of inheritance as described in 4423 RFC5812. 4424 4425 1.0 4426 4427 4428 PktsIn 4429 4430 A group input port. Packets of any arbitrary frame 4431 type are received via the group input with no 4432 additional metadata expected. Inside the LFB, it is 4433 abstracted that each input port instance is connected 4434 to a queue, and the queue is marked with a queue ID 4435 whose value is exactly the same as the index of 4436 corresponding group input port instance. Scheduling 4437 disciplines are applied to all queues and also all 4438 packets in the queues.The group input port property 4439 provides means for the CE to query the capability of 4440 total queue numbers the scheduler supports. 4441 4442 4443 4444 Arbitrary 4445 4446 4447 4448 4449 4450 4451 PktsOut 4452 4453 An output port scheduled packets are output from with 4454 no must metadata associated. 4455 4456 4457 4458 Arbitrary 4459 4460 4461 4462 4463 4464 4465 SchedulingDiscipline 4466 4467 The SchedulingDiscipline component is for the CE to 4468 specify a scheduling discipline to the LFB. 4469 4470 SchdDisciplineType 4471 1 4472 4473 4474 QueueStats 4475 4476 The QueueStats component is defined to allow the CE 4477 to query every queue statistics in the scheduler. 4478 4479 QueueStatsTableType 4480 4481 4482 4483 4484 QueueLenLimit 4485 4486 Allowed maximium length of each queue. The length 4487 unit is in bytes. 4488 4489 uint32 4490 4491 4492 4493 4494 4496 7. LFB Class Use Cases 4498 This section demonstrates examples on how the LFB classes defined by 4499 the Base LFB library in Section 6 can be applied to achieve some 4500 typical router functions. The functions demonstrated are: 4502 o IPv4 forwarding 4504 o ARP processing 4506 It is assumed the LFB topology on the FE described has already been 4507 established by the CE and maps to the use cases illustrated in this 4508 section. 4510 The use cases demonstrated in this section are mere examples and by 4511 no means should be treated as the only way one would construct router 4512 functionality from LFBs; based on the capability of the FE(s), a CE 4513 should be able to express different NE applications. 4515 7.1. IPv4 Forwarding 4517 Figure 1 (Section 3.2.3) shows a typical IPv4 forwarding processing 4518 path by use of the base LFB classes. 4520 A number of EtherPHYCop LFB(Section 5.1.1) instances are used to 4521 describe physical layer functions of the ports. PHYPortID metadata 4522 is generated by EtherPHYCop LFB and is used by all the subsequent 4523 downstream LFBs. An EtherMACIn LFB(Section 5.1.2), which describe 4524 the MAC layer processing, follows every EtherPHYCop LFB. The 4525 EtherMACIn LFB may do a locality check of MAC addresses if the CE 4526 configures the appropriate EtherMACIn LFB component. 4528 Ethernet packets out of the EtherMACIn LFB are sent to an 4529 EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified 4530 into network layer types like IPv4, IPv6, ARP, etc. In the example 4531 use case, every physical Ethernet interface is associated with one 4532 Classifier instance; although not illustrated, it is also feasible 4533 that all physical interfaces are associated with only one Ethernet 4534 Classifier instance. 4536 EtherClassifier uses the PHYPortID metadata, the Ethernet type of the 4537 input packet, and VlanID (if present in the input Ethernet packets), 4538 to decide the packet network layer type and the LFB output port to 4539 the downstream LFB. The EtherClassifier LFB also assigns a new 4540 logical port ID metadata to the packet for later use. The 4541 EtherClassifier may also generate some new metadata for every packet 4542 like EtherType, SrcMAC, DstMAC, LogicPortID, etc for consumption by 4543 downstream LFBs. 4545 If a packet is classified as an IPv4 packet, it is sent downstream to 4546 an IPv4Validator LFB (Section 5.2.1) to validate the IPv4 packet. In 4547 the validator LFB, IPv4 packets are validated and are additionally 4548 classified into either IPv4 unicast packets or multicast packets. 4549 IPv4 unicast packets are sent to downstream to the IPv4UcastLPM LFB 4550 (Section 5.3.1). 4552 The IPv4UcastLPM LFB is where the longest prefix match decision is 4553 made, and a next hop selection is selected. The next hop ID metadata 4554 is generated by the IPv4UcastLPM LFB to be consumed downstream by the 4555 IPv4NextHop LFB (Section 5.3.2). 4557 The IPv4NextHop LFB uses the next hop ID metadata to do derive where 4558 the packet is to go next and the media encapsulation type for the 4559 port, etc. The IPv4NextHop LFB generates the L3PortID metadata used 4560 to identify a next hop output physical/logical port. In the example 4561 use case, the next hop output port is an Ethernet type; as a result, 4562 the packet and its L3 port ID metadata are sent downstream to an 4563 EtherEncap LFB (Section 5.1.4). 4565 The EtherEncap LFB encapsulates the incoming packet into an Ethernet 4566 frame. A BasicMetadataDispatch LFB (Section 5.5.1) follows the 4567 EtherEncap LFB. The BasicMetadataDispatch LFB is where packets are 4568 finally dispatched to different output physical/logical ports based 4569 on the L3PortID metadata sent to the LFB. 4571 7.2. ARP processing 4573 Figure 2 shows the processing path for ARP protocol in the case the 4574 CE implements the ARP processing function. By no means is this the 4575 only way ARP processing could be achieved; as an example ARP 4576 processing could happen at the FE - but that discussion is out of 4577 scope for this use case. 4579 +---+ +---+ 4580 | | ARP packets | | 4581 | |-------------->---------+--->| | To CE 4582 ...-->| | . | | | 4583 | | . | +---+ 4584 | | . | RedirectOut 4585 +---+ ^ 4586 Ether EtherEncap | IPv4 packets lack 4587 Classifier +---+ | address resolution information 4588 | | | 4589 Packets need | |--------->---+ 4590 ...--------->| | 4591 L2 Encapsulation| | 4592 +---+ | | +------+ 4593 | | +-->| |--+ +---+ |Ether | 4594 | | | +---+ | | |--------->|MACOut|-->... 4595 From CE| |--+ +-->| | . +------+ 4596 | |ARP Packets | | . 4597 | |from CE | | . +------+ 4598 | | | |--------> |Ether |-->... 4599 +---+ +---+ |MACOut| 4600 RedirectIn BasicMetadata +------+ 4601 Dispatch 4603 Figure 2: LFB use case for ARP 4605 There are two ways ARP processing could be triggered in the CE as 4606 illustrated in Figure 2: 4608 o ARP packets arriving from outside of the NE. 4610 o IPV4 packets failing to resolve within the FE. 4612 ARP packets from network interfaces are filtered out by 4613 EtherClassifier LFB. The classified ARP packets and associated 4614 metadata are then sent downstream to the RedirectOut LFB 4615 (Section 5.4.2) to be transported to CE. 4617 The EtherEncap LFB, as described earlier, receives packets that need 4618 Ethernet L2 encapsulating. When the EtherEncap LFB fails to find the 4619 necessary L2 Ethernet information to encapsulate the packet with, it 4620 outputs the packet to its ExceptionOut LFB port. Downstream to 4621 EtherEncap LFB's ExceptionOut LFB port is the RedirectOut LFB which 4622 transports the packet to the CE (Section 5.1.4 on EtherEncap LFB for 4623 details). 4625 To achieve its goal, the CE needs to generate ARP request and 4626 response packets and send them to external (to the NE) networks. ARP 4627 request and response packets from the CE are redirected to an FE via 4628 a RedirectIn LFB (Section 5.4.1). 4630 As was the case with forwarded IPv4 packets, outgoing ARP packets are 4631 also encapsulated to Ethernet format by the EtherEncap LFB, and then 4632 dispatched to different interfaces via a BasicMetadataDispatch LFB. 4633 The BasicMetadataDispatch LFB dispatches the packets according to the 4634 L3PortID metadata included in every ARP packet sent from CE. 4636 8. Contributors 4638 The authors would like to thank Jamal Hadi Salim, Ligang Dong, and 4639 Fenggen Jia who made major contributions to the development of this 4640 document. 4642 Jamal Hadi Salim 4643 Mojatatu Networks 4644 Ottawa, Ontario 4645 Canada 4646 Email: hadi@mojatatu.com 4648 Ligang Dong 4649 Zhejiang Gongshang University 4650 149 Jiaogong Road 4651 Hangzhou 310035 4652 P.R.China 4653 Phone: +86-571-28877751 4654 EMail: donglg@mail.zjgsu.edu.cn 4656 Fenggen Jia 4657 National Digital Switching Center(NDSC) 4658 Jianxue Road 4659 Zhengzhou 452000 4660 P.R.China 4661 EMail: jfg@mail.ndsc.com.cn 4663 9. Acknowledgements 4665 This document is based on earlier documents from Joel Halpern, Ligang 4666 Dong, Fenggen Jia and Weiming Wang. 4668 10. IANA Considerations 4670 IANA has created a registry of ForCES LFB Class Names and the 4671 corresponding ForCES LFB Class Identifiers, with the location of the 4672 definition of the ForCES LFB Class, in accordance with the rules to 4673 use the namespace. 4675 The LFB library in this document needs for unique class names and 4676 numeric class identifiers of all LFBs. Besides, this document also 4677 needs to define the following namespaces: 4679 o Metadata ID, defined in Section 4.3 and Section 4.4 4681 o Exception ID, defined in Section 4.4 4683 o Validate Error ID, defined in Section 4.4 4685 10.1. LFB Class Names and LFB Class Identifiers 4687 LFB classes defined by this document belongs to IETF defined LFBs by 4688 Standard Track RFCs. According to IANA, the identifier namespace for 4689 these LFB classes is from 3 to 65535. 4691 The assignment of LFB class names and LFB class identifiers is as in 4692 the following table. 4694 +-----------+---------------+------------------------+--------------+ 4695 | LFB Class | LFB Class Name| Description | Reference | 4696 | Identifier| | | | 4697 +-----------+---------------+------------------------+--------------+ 4698 | 3 | EtherPHYCop | Define an Ethernet port| RFC????(this| 4699 | | | abstracted at physical | document) | 4700 | | | layer. | Section 5.1.1| 4701 | | | | | 4702 | 4 | EtherMACIn | Define an Ethernet | RFC???? | 4703 | | | input port at MAC data | Section 5.1.2| 4704 | | | link layer. | | 4705 | | | | | 4706 | 5 |EtherClassifier| Define the process to | RFC???? | 4707 | | | decapsulate Ethernet | Section 5.1.3| 4708 | | | packets and classify | | 4709 | | | the packets. | | 4710 | | | | | 4711 | 6 | EtherEncap | Define the process to | RFC???? | 4712 | | | encapsulate IP packets | Section 5.1.4| 4713 | | | to Ethernet packets. | | 4714 | | | | | 4715 | 7 | EtherMACOut | Define an Ethernet | RFC ???? | 4716 | | | output port at MAC | Section 5.1.5| 4717 | | | data link layer. | | 4718 | | | | | 4719 | 8 | IPv4Validator | Perform IPv4 packets | RFC ???? | 4720 | | | validation. | Section 5.2.1| 4721 | | | | | 4722 | 9 | IPv6Validator | Perform IPv6 packets | RFC ???? | 4723 | | | validation. | Section 5.2.2| 4724 | | | | | 4725 | 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? | 4726 | | | Prefix Match Lookup. | Section 5.3.1| 4727 | | | | | 4728 | 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC ???? | 4729 | | | Prefix Match Lookup. | Section 5.3.3| 4730 | | | | | 4731 | 12 | IPv4NextHop | Define the process of | RFC ??? | 4732 | | | selecting Ipv4 next hop| Section 5.3.2| 4733 | | | action. | | 4734 | | | | | 4735 | 13 | IPv6NextHop | Define the process of | RFC ??? | 4736 | | | selecting Ipv6 next hop| Section 5.3.4| 4737 | | | action. | | 4738 | | | | | 4739 | 14 | RedirectIn | Define the process for | RFC ??? | 4740 | | | CE to inject data | Section 5.4.1| 4741 | | | packets into FE LFB | | 4742 | | | topology. | | 4743 | | | | | 4744 | 15 | RedirectOut | Define the process for | RFC ??? | 4745 | | | LFBs in FE to deliver | Section 5.4.2| 4746 | | | data packets to CE. | | 4747 | | | | | 4748 | 16 | BasicMetadata | Dispatch input packets | RFC ??? | 4749 | | Dispatch | to a group output | Section 5.5.1| 4750 | | | according to a metadata| | 4751 | | | | | 4752 | 17 | Generic | Define a preliminary | RFC ???? | 4753 | | Scheduler | generic scheduling | Section 5.5.2| 4754 | | | process. | | 4755 +-----------+---------------+------------------------+--------------+ 4757 Table 1 4759 10.2. Metadata ID 4761 The Metadata ID namespace is 32 bits long. The following is the 4762 guideline for managing the namespace. 4764 Metadata ID 0x00000000-0x7FFFFFFF 4765 Metadata with IDs in this range are Specification Required 4766 [RFC5226]. A metadata ID using this range MUST be documented in 4767 an RFC or other permanent and readily available references. 4769 Values assigned by this specification: 4771 +--------------+-------------------------+--------------------------+ 4772 | Value | Name | Definition | 4773 +--------------+-------------------------+--------------------------+ 4774 | 0x00000001 | PHYPortID | See Section 4.4 | 4775 | 0x00000002 | SrcMAC | See Section 4.4 | 4776 | 0x00000003 | DstMAC | See Section 4.4 | 4777 | 0x00000004 | LogicalPortID | See Section 4.4 | 4778 | 0x00000005 | EtherType | See Section 4.4 | 4779 | 0x00000006 | VlanID | See Section 4.4 | 4780 | 0x00000007 | VlanPriority | See Section 4.4 | 4781 | 0x00000008 | NextHopIPv4Addr | See Section 4.4 | 4782 | 0x00000009 | NextHopIPv6Addr | See Section 4.4 | 4783 | 0x0000000A | HopSelector | See Section 4.4 | 4784 | 0x0000000B | ExceptionID | See Section 4.4 | 4785 | 0x0000000C | ValidateErrorID | See Section 4.4 | 4786 | 0x0000000D | L3PortID | See Section 4.4 | 4787 | 0x0000000E | RedirectIndex | See Section 4.4 | 4788 | 0x0000000F | MediaEncapInfoIndex | See Section 4.4 | 4789 +--------------+-------------------------+--------------------------+ 4791 Table 2 4793 Metadata ID 0x80000000-0xFFFFFFFF 4794 Metadata IDs in this range are reserved for vendor private 4795 extensions and are the responsibility of individuals. 4797 10.3. Exception ID 4799 The Exception ID namespace is 32 bits long. The following is the 4800 guideline for managing the namespace. 4802 Exception ID 0x00000000-0x7FFFFFFF 4803 Exception IDs in this range are Specification Required [RFC5226]. 4804 An exception ID using this range MUST be documented in an RFC or 4805 other permanent and readily available references. 4807 Values assigned by this specification: 4809 +--------------+---------------------------------+------------------+ 4810 | Value | Name | Definition | 4811 +--------------+---------------------------------+------------------+ 4812 | 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 | 4813 | 0x00000001 | ClassifyNoMatching | See Section 4.4 | 4814 | 0x00000002 | MediaEncapInfoIndexInvalid | See Section 4.4 | 4815 | 0x00000003 | EncapTableLookupFailed | See Section 4.4 | 4816 | 0x00000004 | BadTTL | See Section 4.4 | 4817 | 0x00000005 | IPv4HeaderLengthMismatch | See Section 4.4 | 4818 | 0x00000006 | RouterAlertOptions | See Section 4.4 | 4819 | 0x00000007 | IPv6HopLimitZero | See Section 4.4 | 4820 | 0x00000008 | IPv6NextHeaderHBH | See Section 4.4 | 4821 | 0x00000009 | SrcAddressExecption | See Section 4.4 | 4822 | 0x0000000A | DstAddressExecption | See Section 4.4 | 4823 | 0x0000000B | LPMLookupFailed | See Section 4.4 | 4824 | 0x0000000C | HopSelectorInvalid | See Section 4.4 | 4825 | 0x0000000D | NextHopLookupFailed | See Section 4.4 | 4826 | 0x0000000E | FragRequired | See Section 4.4 | 4827 | 0x0000000F | MetadataNoMatching | See Section 4.4 | 4828 +--------------+---------------------------------+------------------+ 4830 Table 3 4832 Exception ID 0x80000000-0xFFFFFFFF 4833 Exception IDs in this range are reserved for vendor private 4834 extensions and are the responsibility of individuals. 4836 10.4. Validate Error ID 4838 The Validate Error ID namespace is 32 bits long. The following is 4839 the guideline for managing the namespace. 4841 Validate Error ID 0x00000000-0x7FFFFFFF 4842 Validate Error IDs in this range are Specification Required 4843 [RFC5226]. A Validate Error ID using this range MUST be 4844 documented in an RFC or other permanent and readily available 4845 references. 4847 Values assigned by this specification: 4849 +--------------+---------------------------------+------------------+ 4850 | Value | Name | Definition | 4851 +--------------+---------------------------------+------------------+ 4852 | 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 | 4853 | 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 | 4854 | 0x00000002 | NotIPv4Packet | See Section 4.4 | 4855 | 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 | 4856 | 0x00000004 | InvalidIPv4LengthFieldSize | See Section 4.4 | 4857 | 0x00000005 | InvalidIPv4Checksum | See Section 4.4 | 4858 | 0x00000006 | InvalidIPv4SrcAddr | See Section 4.4 | 4859 | 0x00000007 | InvalidIPv4DstAddr | See Section 4.4 | 4860 | 0x00000008 | InvalidIPv6PakcetSize | See Section 4.4 | 4861 | 0x00000009 | NotIPv6Packet | See Section 4.4 | 4862 | 0x0000000A | InvalidIPv6SrcAddr | See Section 4.4 | 4863 | 0x0000000B | InvalidIPv6DstAddr | See Section 4.4 | 4864 +--------------+---------------------------------+------------------+ 4865 Table 4 4867 Validate Error ID 0x80000000-0xFFFFFFFF 4868 Validate Error IDs in this range are reserved for vendor private 4869 extensions and are the responsibility of individuals. 4871 11. Security Considerations 4873 The ForCES framework document [RFC3746] provides a comprehensive 4874 security analysis for the overall ForCES architecture. For example, 4875 the ForCES protocol entities must be authenticated per the ForCES 4876 requirements before they can access the information elements 4877 described in this document via ForCES. Access to the information 4878 contained in this document is accomplished via the ForCES 4879 protocol[RFC5810], which is defined in separate documents, and thus 4880 the security issues will be addressed there. 4882 12. References 4884 12.1. Normative References 4886 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 4887 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 4888 Control Element Separation (ForCES) Protocol 4889 Specification", RFC 5810, March 2010. 4891 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 4892 Element Separation (ForCES) Forwarding Element Model", 4893 RFC 5812, March 2010. 4895 12.2. Informative References 4897 [RFC1122] Braden, R., "Requirements for Internet Hosts - 4898 Communication Layers", STD 3, RFC 1122, October 1989. 4900 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 4901 RFC 1812, June 1995. 4903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4904 Requirement Levels", BCP 14, RFC 2119, March 1997. 4906 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4907 (IPv6) Specification", RFC 2460, December 1998. 4909 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 4910 June 1999. 4912 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 4913 Text on Security Considerations", BCP 72, RFC 3552, 4914 July 2003. 4916 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 4917 of IP Control and Forwarding", RFC 3654, November 2003. 4919 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 4920 "Forwarding and Control Element Separation (ForCES) 4921 Framework", RFC 3746, April 2004. 4923 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4924 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 4925 May 2008. 4927 Authors' Addresses 4929 Weiming Wang 4930 Zhejiang Gongshang University 4931 18 Xuezheng Str., Xiasha University Town 4932 Hangzhou, 310018 4933 P.R.China 4935 Phone: +86 571 28877721 4936 Email: wmwang@zjsu.edu.cn 4938 Evangelos Haleplidis 4939 University of Patras 4940 Patras, 4941 Greece 4943 Email: ehalep@ece.upatras.gr 4945 Kentaro Ogawa 4946 NTT Corporation 4947 Tokyo, 4948 Japan 4950 Email: ogawa.kentaro@lab.ntt.co.jp 4952 Chuanhuang Li 4953 Hangzhou H3C Tech. Co., Ltd. 4954 310 Liuhe Road, Zhijiang Science Park 4955 Hangzhou, 310053 4956 P.R.China 4958 Phone: +86 571 86760000 4959 Email: chuanhuang_li@zjsu.edu.cn 4961 Halpern Joel 4962 Ericsson 4963 P.O. Box 6049 4964 Leesburg, 20178 4965 VA 4967 Phone: +1 703 371 3043 4968 Email: joel.halpern@ericsson.com