idnits 2.17.1 draft-ietf-forces-lfb-lib-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2013) is 4039 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 512, but not defined == Unused Reference: 'RFC2629' is defined on line 5053, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 5056, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 5060, 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 (~~), 5 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 30, 2013 University of Patras 6 K. Ogawa 7 NTT Corporation 8 C. Li 9 Hangzhou DPtech 10 J. Halpern 11 Ericsson 12 March 29, 2013 14 ForCES Logical Function Block (LFB) Library 15 draft-ietf-forces-lfb-lib-12 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 30, 2013. 44 Copyright Notice 46 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . 11 69 3.2.3. Sample LFB Class Application . . . . . . . . . . . . 12 70 3.3. Document Structure . . . . . . . . . . . . . . . . . . . 13 71 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 14 73 4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.1.2. Compound Struct . . . . . . . . . . . . . . . . . . . 15 75 4.1.3. Compound Array . . . . . . . . . . . . . . . . . . . 15 76 4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 16 77 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 16 78 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . 48 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 . . . . . . . . . . . . . . . . . . . . 54 88 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55 89 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 57 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 . . . . . . . . . . . . . . . . . . 69 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 . . . . . . . . . . . . . . . . . . . . . 102 104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 105 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106 106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107 107 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 107 108 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 109 109 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 109 110 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 110 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 112 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 113 114 12.2. Informative References . . . . . . . . . . . . . . . . . 113 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115 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. 208 Physical Port - A port refers to a physical media input port or 209 output port of an FE. A physical port is usually assigned with a 210 physical port ID, abbreviated with a PHYPortID. This document 211 mainly deals with physical ports with Ethernet media. 213 Logical Port - A conceptually virtual port at data link layer (L2) 214 or network layer (L3). A logical port is usually assigned with a 215 logical port ID, abbreviated with a LogicalPortID. The logical 216 ports can be further categorized with a L2 logical port or a L3 217 logical port. An L2 logical port can be assigned with a L2 218 logical port ID, abbreviated with a L2PortID. An L3 logical port 219 can be assigned with a L3 logical port ID, abbreviated with a 220 L3PortID. MAC layer VLAN ports belongs to L2 logical ports as 221 well as logical ports. 223 LFB Port - The connection points where one LFB can be connected to 224 another within an FE. As described in [RFC5812], the CE can 225 connect LFBs together by establishing connections between an 226 output port of one LFB instance and an input port of another LFB 227 instance. Also see Section 3.2 of [RFC5812] for more details. 229 Singleton Port - A named input or output port of an LFB. This 230 port is referred to by a name. When the context is clear, the 231 term singleton by itself is used to refer to a singleton port. 233 Group Port - A named collection of input or output ports of an 234 LFB. A group port is referred to by a name. Whereas, a group 235 port consists of a number of port instances, which are referred to 236 by a combination of a name and an index. 238 LFB Class Library - The LFB class library is a set of LFB classes 239 that has been identified as the most common functions found in 240 most FEs and hence should be defined first by the ForCES Working 241 Group. The LFB Class Library is defined by this document. 243 3. Introduction 245 [RFC3746] specifies Forwarding and Control Element Separation 246 (ForCES) framework. In the framework, Control Elements (CEs) 247 configure and manage one or more separate Forwarding Elements (FEs) 248 within a Network Element (NE) by use of a ForCES protocol. [RFC5810] 249 specifies the ForCES protocol. [RFC5812] specifies the Forwarding 250 Element (FE) model. In the model, resources in FEs are described by 251 classes of Logical Function Blocks (LFBs). The FE model defines the 252 structure and abstract semantics of LFBs, and provides XML schema for 253 the definitions of LFBs. 255 This document conforms to the specifications of the FE model 256 [RFC5812] and specifies detailed definitions of classes of LFBs, 257 including detailed XML definitions of LFBs. These LFBs form a base 258 LFB library for ForCES. LFBs in the base library are expected to be 259 combined to form an LFB topology for a typical router to implement IP 260 forwarding. It should be emphasized that an LFB is an abstraction of 261 functions rather than its implementation details. The purpose of the 262 LFB definitions is to represent functions so as to provide 263 interoperability between separate CEs and FEs. 265 More LFB classes with more functions may be developed in future time 266 and documented by IETF. Vendors may also develop proprietary LFB 267 classes as described in the FE model [RFC5812]. 269 3.1. Scope of the Library 271 It is intended that the LFB classes described in this document are 272 designed to provide the functions of a typical router. [RFC1812] 273 specifies that a typical router is expected to provide functions to: 275 (1) Interface to packet networks and implement the functions 276 required by that network. These functions typically include: 278 * Encapsulating and decapsulating the IP datagrams with the 279 connected network framing (e.g., an Ethernet header and 280 checksum), 282 * Sending and receiving IP datagrams up to the maximum size 283 supported by that network, this size is the network's Maximum 284 Transmission Unit or MTU, 286 * Translating the IP destination address into an appropriate 287 network-level address for the connected network (e.g., an 288 Ethernet hardware address), if needed, and 290 * Responding to network flow control and error indications, if 291 any. 293 (2) Conform to specific Internet protocols including the Internet 294 Protocol (IPv4 and/or IPv6), Internet Control Message Protocol 295 (ICMP), and others as necessary. 297 (3) Receive and forward Internet datagrams. Important issues in 298 this process are buffer management, congestion control, and 299 fairness. 301 * Recognizes error conditions and generates ICMP error and 302 information messages as required. 304 * Drops datagrams whose time-to-live fields have reached zero. 306 * Fragments datagrams when necessary to fit into the MTU of the 307 next link or interface. 309 (4) Choose a next hop destination for each IP datagram, based on the 310 information in its routing database. 312 (5) Usually support an interior gateway protocol (IGP) to carry out 313 distributed routing and reachability algorithms with the other 314 routers in the same autonomous system. In addition, some 315 routers will need to support an exterior gateway protocol (EGP) 316 to exchange topological information with other autonomous 317 systems. For all routers, it is essential to provide ability to 318 manage static routing items. 320 (6) Provide network management and system support facilities, 321 including loading, debugging, status reporting, statistcs query, 322 exception reporting and control. 324 The classical IP router utilizing the ForCES framework constitutes a 325 CE running some controlling IGP and/or EGP function or static route 326 setup and FEs implementing using Logical Function Blocks (LFBs) 327 conforming to the FE model[RFC5812] specifications. The CE, in 328 conformance to the ForCES protocol[RFC5810] and the FE model 329 [RFC5812] specifications, instructs the LFBs on the FE how to treat 330 received/sent packets. 332 Packets in an IP router are received and transmitted on physical 333 media typically referred to as "ports". Different physical port 334 media will have different ways for encapsulating outgoing frames and 335 decapsulating incoming frames. The different physical media will 336 also have different attributes that influence its behavior and how 337 frames get encapsulated or decapsulated. This document will only 338 deal with Ethernet physical media. Other future documents may deal 339 with other type of media. This document will also interchangeably 340 refer to a port to be an abstraction that constitutes a PHY and a MAC 341 as described by the LFBs like EtherPHYCop, EtherMACIn, and 342 EtherMACOut. 344 IP packets emanating from port LFBs are then processed by a 345 validation LFB before being further forwarded to the next LFB. After 346 the validation process the packet is passed to an LFB where IP 347 forwarding decision is made. In the IP Forwarding LFBs, a Longest 348 Prefix Match LFB is used to look up the destination information in a 349 packet and select a next hop index for sending the packet onward. A 350 next hop LFB uses the next hop index metadata to apply the proper 351 headers to the IP packets, and direct them to the proper egress. 352 Note that in the process of IP packets processing, in this document, 353 we are adhering to the weak-host model [RFC1122] since that is the 354 most usable model for a packet processing Network Element. 356 3.2. Overview of LFB Classes in the Library 358 It is critical to classify functional requirements into various 359 classes of LFBs and construct a typical but also flexible enough base 360 LFB library for various IP forwarding equipments. 362 3.2.1. LFB Design Choices 364 A few design principles were factored into choosing how the base LFBs 365 looked like. These are: 367 o If a function can be designed by either one LFB or two or more 368 LFBs with the same cost, the choice is to go with two or more LFBs 369 so as to provide more flexibility for implementers. 371 o An LFB should take advantage of its independence as much as 372 possible and have minimal coupling with other LFBs. The coupling 373 may be from LFB attributes definitions as well as physical 374 implementations. 376 o Unless there is a clear difference in functionality, similar 377 packet processing in the base LFB library should not be 378 represented simultaneously as two or more LFBs. For instance, it 379 should not be simultaneously defined with two different LFBs for 380 the same next hop processing. Or else, it may add extra burden on 381 implementation to achieve interoperability. 383 3.2.2. LFB Class Groupings 385 The document defines groups of LFBs for typical router function 386 requirements: 388 (1) A group of Ethernet processing LFBs are defined to abstract the 389 packet processing for Ethernet as the port media type. As the 390 most popular media type with rich processing features, Ethernet 391 media processing LFBs was a natural choice. Definitions for 392 processing of other port media type like POS or ATM may be 393 incorporated in the library in future version of the document or 394 in a future separate document. The following LFBs are defined 395 for Ethernet processing: 397 * EtherPHYCop (Section 5.1.1) 399 * EtherMACIn (Section 5.1.2) 401 * EtherClassifier (Section 5.1.3) 403 * EtherEncap (Section 5.1.4) 405 * EtherMACOut (Section 5.1.5) 407 (2) A group of LFBs are defined for IP packet validation process. 408 The following LFBs are defined for IP validation processing: 410 * IPv4Validator (Section 5.2.1) 412 * IPv6Validator (Section 5.2.2) 414 (3) A group of LFBs are defined to abstract IP forwarding process. 415 The following LFBs are defined for IP forwarding processing: 417 * IPv4UcastLPM (Section 5.3.1) 419 * IPv4NextHop (Section 5.3.2) 421 * IPv6UcastLPM (Section 5.3.3) 423 * IPv6NextHop (Section 5.3.4) 425 (4) A group of LFBs are defined to abstract the process for redirect 426 operation, i.e., data packet transmission between CE and FEs. 427 The following LFBs are defined for redirect processing: 429 * RedirectIn (Section 5.4.1) 430 * RedirectOut (Section 5.4.2) 432 (5) A group of LFBs are defined for abstracting some general purpose 433 packet processing. These processing processes are usually 434 general to many processing locations in an FE LFB topology. The 435 following LFBs are defined for redirect processing: 437 * BasicMetadataDispatch (Section 5.5.1) 439 * GenericScheduler (Section 5.5.2) 441 3.2.3. Sample LFB Class Application 443 Although Section 7 will present use cases for LFBs defined in this 444 document, this section shows a simple sample LFB class application in 445 advance so that readers can get a quick overlook of the LFB classes 446 with the usage. 448 Figure 1 shows a simple LFB processing path for Ethernet packets 449 entered from Ethernet physical ports. 451 +-----+ +------+ 452 | |EtherPHYIn | | from some LFB(s) which 453 | |<---------------|Ether |<---------- generate Ethernet 454 | | |MACOut| packets 455 | | | LFB | 456 |Ether| +------+ 457 |PHY | +------+ 458 |Cop | | | 459 |LFB |EtherPHYOut | Ether| to some LFB(s) which 460 | |--------------->| MACIn|----------> may classify Ethernet 461 | | | LFB | packets and do IP layer 462 | | | | processing 463 +-----+ +------+ 465 Figure 1: A simple sample LFB use case 467 In the figure, Ethernet packets from outer networks enter via the 468 EtherPHYCop LFB(Section 5.1.1), which describes Ethernet copper 469 interface property(like the link speed) at physical layer. After 470 physical layer process, Ethernet packets are delivered to EtherMACIn 471 LFB(Section 5.1.2) to describe its MAC layer processing 472 functions(like locality check). The packets after EtherMACIn LFB may 473 require further processing to implement various functions(like IP 474 layer forwarding),therefore some LFBs may follow the EtherMACIn LFB 475 in topology to describe followed processing functions. 477 Meanwhile, packets generated by some LFB(s) may need to be submitted 478 to outer physical networks. The process is described in the figure 479 by an EtherMACOut LFB(Section 5.1.5) at MAC layer and the EtherPHYCop 480 LFB at physical layer. 482 3.3. Document Structure 484 Base type definitions, including data types, packet frame types, and 485 metadata types are presented in advance for definitions of various 486 LFB classes. Section 4 (Base Types section) provides a description 487 on the base types used by this LFB library. To enable extensive use 488 of these base types by other LFB class definitions, the base type 489 definitions are provided as a separate library. 491 Within every group of LFB classes, a set of LFBs are defined for 492 individual function purposes. Section 5 (LFB Class Descriptions 493 section) provides text descriptions on the individual LFBs. Note 494 that for a complete definition of an LFB, a text description as well 495 as a XML definition is required. 497 LFB classes are finally defined by XML with specifications and schema 498 defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB 499 Definitions section) provides the complete XML definitions of the 500 base LFB classes library. 502 Section 7 provides several use cases on how some typical router 503 functions can be implemented using the base LFB library defined in 504 this document. 506 4. Base Types 508 The FE model [RFC5812] has specified predefined (built-in) atomic 509 data-types as below: 511 char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], 512 string, byte[N], boolean, octetstring[N], float16, float32, float64. 514 Note that, unlike SNMP information model SMI([RFC2578]), the FE model 515 has not defined specific atomic data type for counting purpose. This 516 document follows not to define specific counter types. To describe 517 LFB elements for packet statistics which actually require counters on 518 packets, an unsigned integer, like an uint32 or an uint64 is adopted. 519 This document states that any LFB element defined for counter purpose 520 is specified to monotonically increase until it reaches a maximum 521 value, when it wraps around and starts increasing again from zero. 522 This document also states that it is implementation's issue how the 523 unsigned integer element might be maintained to cope with issues like 524 counter discontinuities when a counter wraps or is reset by any 525 reasons. If a CE is expected to understand more meanings of the 526 counter element than stated above, a private definition on the 527 element between CE and FE may be required. 529 Based on the atomic data types and with the use of type definition 530 elements in the FE model XML schema, new data types, packet frame 531 types, and metadata types can be defined. 533 To define a base LFB library for typical router functions, a set of 534 base data types, frame types, and metadata types should be defined. 535 This section provides a brief description of the base types and a 536 full XML definition of them as well. 538 The base type XML definitions are provided with a separate XML 539 library file named "BaseTypeLibrary". Users can refer to this 540 library by the statement: 542 544 4.1. Data Types 546 Data types defined in the base type library are categorized by types 547 of atomic, compound struct, and compound array. 549 4.1.1. Atomic 551 The following data types are defined as atomic data types and put in 552 the base type library: 554 Data Type Name Brief Description 555 -------------- ----------------- 556 IPv4Addr IPv4 address 557 IPv6Addr IPv6 address 558 IEEEMAC IEEE MAC address 559 LANSpeedType LAN speed by value types 560 DuplexType Duplex types 561 PortStatusType The possible types of port status, used for 562 both administrative and operative status. 563 VlanIDType The type of VLAN ID 564 VlanPriorityType The type of VLAN priority 565 SchdDisciplineType Scheduling discipline type 567 4.1.2. Compound Struct 569 The following compound struct types are defined in the base type 570 library: 572 Data Type Name Brief Description 573 -------------- ----------------- 574 EtherDispatchEntryType Entry type for Ethernet dispatch table 575 VlanInputTableEntryType Entry type for VLAN input table 576 EncapTableEntryType Entry type for Ethernet encapsulation table 577 MACInStatsType Statistics type for EtherMACIn LFB 578 MACOutStatsType Statistics type for EtherMACOut LFB 579 EtherClassifyStatsType Entry type for statistics table in 580 EtherClassifier LFB. 581 IPv4PrefixInfoType Entry type for IPv4 prefix table 582 IPv6PrefixInfoType Entry type for IPv6 prefix table 583 IPv4NextHopInfoType Entry type for IPv4 next hop table 584 IPv6NextHopInfoType Entry type for IPv6 next hop table 585 IPv4ValidatorStatsType Statistics type in IPv4validator LFB 586 IPv6ValidatorStatsType Statistics type in IPv6validator LFB 587 IPv4UcastLPMStatsType Statistics type in IPv4UcastLPM LFB 588 IPv6UcastLPMStatsType Statistics type in IPv6UcastLPM LFB 589 QueueStatsType Entry type for queue depth table 590 MetadataDispatchType Entry type for metadata dispatch table 592 4.1.3. Compound Array 594 Compound array types are mostly created based on compound struct 595 types for LFB table components. The following compound array types 596 are defined in this base type library: 598 Data Type Name Brief Description 599 -------------- ----------------- 600 EtherClassifyStatsTableType Type for Ethernet classifier statistics 601 information table. 602 EtherDispatchTableType Type for Ethernet dispatch table 603 VlanInputTableType Type for VLAN input table 604 EncapTableType Type for Ethernet encapsulation table 605 IPv4PrefixTableType Type for IPv4 prefix table 606 IPv6PrefixTableType Type for IPv6 prefix table 607 IPv4NextHopTableType Type for IPv4 next hop table 608 IPv6NextHopTableType Type for IPv6 next hop table 609 MetadataDispatchTableType Type for Metadata dispatch table 610 QueueStatsTableType Type for Queue depth table 612 4.2. Frame Types 614 According to FE model [RFC5812], frame types are used in LFB 615 definitions to define packet frame types both an LFB expects at its 616 input port and the LFB emits at its output port. The 617 element in the FE model is used to define a new frame type. 619 The following frame types are defined in the base type library: 621 Frame Name Brief Description 622 -------------- ---------------- 623 EthernetII An Ethernet II frame 624 ARP An ARP packet frame 625 IPv4 An IPv4 packet frame 626 IPv6 An IPv6 packet frame 627 IPv4Unicast An IPv4 unicast packet frame 628 IPv4Multicast An IPv4 multicast packet frame 629 IPv6Unicast An IPv6 unicast packet frame 630 IPv6Multicast An IPv6 multicast packet frame 631 Arbitrary Any type of packet frames 633 4.3. MetaData Types 635 LFB Metadata is used to communicate per-packet state from one LFB to 636 another. The element in the FE model is used to define 637 a new metadata type. 639 The following metadata types are currently defined in the base type 640 library. 642 Metadata Name Metadata ID Brief Description 643 ------------ ---------- ------------- 644 PHYPortID 1 Metadata indicating a physical port ID 645 SrcMAC 2 Metadata indicating a source MAC address 646 DstMAC 3 Metadata indicating a destination MAC 647 address. 648 LogicalPortID 4 Metadata of a logical port ID 649 EtherType 5 Metadata indicating an Ethernet type 650 VlanID 6 Metadata of a VLAN ID 651 VlanPriority 7 Metadata of a VLAN priority 652 NextHopIPv4Addr 8 Metadata representing a next hop IPv4 653 address. 654 NextHopIPv6Addr 9 Metadata representing a next hop IPv6 655 address. 656 HopSelector 10 Metadata indicating a hop selector 657 ExceptionID 11 Metadata indicating exception types for 658 exceptional cases during LFB processing. 659 ValidateErrorID 12 Metadata indicating error types when a 660 packet passes validation process. 661 L3PortID 13 Metadata indicating ID of an L3 logical 662 port. 663 RedirectIndex 14 Metadata that CE sends to RedirectIn LFB, 664 indicating an associated packet a group 665 output port index of the LFB. 666 MediaEncapInfoIndex 15 A search key a packet uses to look up a 667 table in related LFBs to select an 668 encapsulation media. 670 4.4. XML for Base Type Library 672 673 676 677 678 EthernetAll 679 Packet with any Ethernet type 680 681 682 EthernetII 683 Packet with Ethernet II type 684 685 686 ARP 687 ARP packet 688 689 690 IPv4 691 IPv4 packet 692 693 694 IPv6 695 IPv6 packet 696 697 698 IPv4Unicast 699 IPv4 unicast packet 700 701 702 IPv4Multicast 703 IPv4 multicast packet 704 705 706 IPv6Unicast 707 IPv6 unicast packet 708 709 710 IPv6Multicast 711 IPv6 multicast packet 712 713 714 Arbitrary 715 Any type of packet 716 717 718 719 720 IPv4Addr 721 IPv4 address 722 byte[4] 723 724 725 IPv6Addr 726 IPv6 address 727 byte[16] 728 729 730 IEEEMAC 731 IEEE MAC address 732 byte[6] 733 734 735 LANSpeedType 736 LAN speed type 737 738 uint32 739 740 741 LAN_SPEED_NONE 742 Nothing connected 743 744 745 LAN_SPEED_10M 746 10M Ethernet 747 748 749 LAN_SPEED_100M 750 100M Ethernet 751 752 753 LAN_SPEED_1G 754 1G Ethernet 755 756 757 LAN_SPEED_10G 758 10G Ethernet 759 760 761 LAN_SPEED_40G 762 40G Ethernet 763 764 765 LAN_SPEED_100G 766 100G Ethernet 767 768 769 LAN_SPEED_400G 770 400G Ethernet 771 772 773 LAN_SPEED_1T 774 1T Ethernet 775 776 777 LAN_SPEED_OTHER 778 Other LAN speed type 779 780 781 LAN_SPEED_AUTO 782 LAN speed by auto negotiation 783 784 786 787 788 789 DuplexType 790 Duplex mode type 791 792 uint32 793 794 795 Auto 796 Auto negotiation 797 798 799 HalfDuplex 800 Half duplex 801 802 803 FullDuplex 804 Full duplex 805 806 807 808 809 810 PortStatusType 811 812 Type for port status, used for both administrative and 813 operative status. 814 815 816 uchar 817 818 819 Disabled 820 Port disabled 821 822 823 Up 824 Port up 825 826 827 Down 828 Port down 829 830 831 832 833 834 MACInStatsType 835 836 Data type defined for statistics in EtherMACIn LFB. 837 838 839 840 NumPacketsReceived 841 Number of packets received 842 uint64 843 844 845 NumPacketsDropped 846 Number of packets dropped 847 uint64 848 849 850 851 852 MACOutStatsType 853 854 Data type defined for statistics in EtherMACOut LFB. 855 856 857 858 NumPacketsTransmitted 859 Number of packets transmitted 860 uint64 861 862 863 NumPacketsDropped 864 Number of packets dropped 865 uint64 866 867 868 869 870 EtherDispatchEntryType 871 872 Data type defined for entry of Ethernet dispatch 873 table in EtherClassifier LFB. 874 875 876 877 LogicalPortID 878 Logical port ID 879 uint32 880 881 882 EtherType 883 884 The Ethernet type of the Ethernet packet. 885 886 uint16 887 888 889 Reserved 890 891 A reserved bit space mainly for purpose of padding 892 and packing efficiency. 893 894 uint16 895 896 897 LFBOutputSelectIndex 898 899 Index for a packet to select an instance in the 900 group output port of EtherClassifier LFB to output. 901 902 uint32 903 904 905 906 907 EtherDispatchTableType 908 909 Data type defined for Ethernet dispatch table in 910 EtherClassifier LFB. The table is composed of an array 911 of entries with EtherDispatchEntryType data type. 912 913 914 EtherDispatchEntryType 915 916 917 918 VlanIDType 919 Data type for VLAN ID 920 921 uint16 922 923 924 925 926 927 928 VlanPriorityType 929 Data type for VLAN priority 930 931 uchar 932 933 934 935 936 937 938 VlanInputTableEntryType 939 940 Data type for entry of VLAN input table in EtherClassifier 941 LFB. Each entry of the table contains an incoming port ID, 942 a VLAN ID and a logical port ID. Every input packet is 943 assigned with a new logical port ID according to the 944 packet incoming port ID and the VLAN ID. 945 946 947 948 IncomingPortID 949 The incoming port ID 950 uint32 951 952 953 VlanID 954 The VLAN ID 955 VlanIDType 956 957 958 Reserved 959 960 A reserved bit space mainly for purpose of padding 961 and packing efficiency. 962 963 uint16 964 965 966 LogicalPortID 967 The logical port ID 968 uint32 969 970 971 972 973 VlanInputTableType 974 975 Data type for the VLAN input table in EtherClassifier 976 LFB. The table is composed of an array of entries with 977 VlanInputTableEntryType. 979 980 981 VlanInputTableEntryType 982 983 984 985 EtherClassifyStatsType 986 987 Data type for entry of statistics table in EtherClassifier 988 LFB. 989 990 991 992 EtherType 993 994 The Ethernet type of the Ethernet packet. 995 996 uint16 997 998 999 Reserved 1000 1001 A reserved bit space mainly for purpose of padding 1002 and packing efficiency. 1003 1004 uint16 1005 1006 1007 PacketsNum 1008 Packets number 1009 uint64 1010 1011 1012 1013 1014 EtherClassifyStatsTableType 1015 1016 Data type for statistics table in EtherClassifier LFB. 1017 1018 1019 EtherClassifyStatsType 1020 1021 1022 1023 IPv4ValidatorStatsType 1024 1025 Data type for statistics in IPv4validator LFB. 1026 1027 1028 1029 badHeaderPkts 1030 Number of packets with bad header 1031 uint64 1032 1033 1034 badTotalLengthPkts 1035 1036 Number of packets with bad total length 1037 1038 uint64 1039 1040 1041 badTTLPkts 1042 Number of packets with bad TTL 1043 uint64 1044 1045 1046 badChecksumPkts 1047 Number of packets with bad checksum 1048 uint64 1049 1050 1051 1052 1053 IPv6ValidatorStatsType 1054 1055 Data type for statistics in IPv6validator LFB. 1056 1057 1058 1059 badHeaderPkts 1060 Number of packets with bad header 1061 uint64 1062 1063 1064 badTotalLengthPkts 1065 1066 Number of packets with bad total length. 1067 1068 uint64 1069 1070 1071 badHopLimitPkts 1072 1073 Number of packets with bad hop limit. 1074 1075 uint64 1076 1077 1078 1079 1080 IPv4PrefixInfoType 1081 Data type for entry of IPv4 longest prefix match 1082 table in IPv4UcastLPM LFB. The destination IPv4 address 1083 of every input packet is used as a search key to look up 1084 the table to find out a next hop selector. 1085 1086 1087 IPv4Address 1088 The destination IPv4 address 1089 IPv4Addr 1090 1091 1092 Prefixlen 1093 The prefix length 1094 1095 uchar 1096 1097 1098 1099 1100 1101 1102 ECMPFlag 1103 The ECMP flag 1104 1105 boolean 1106 1107 1108 False 1109 1110 ECMP false, indicating the route 1111 does not have multiple next hops. 1112 1113 1114 1115 True 1116 1117 ECMP true, indicating the route 1118 has multiple next hops. 1119 1120 1121 1122 1124 1125 1126 DefaultRouteFlag 1127 Default route flag 1128 1129 boolean 1130 1131 1132 False 1133 1134 Default route false, indicating the 1135 route is not a default route. 1136 1137 1138 1139 True 1140 1141 Default route true, indicating the 1142 route is a default route. 1143 1144 1145 1146 1147 1148 1149 Reserved 1150 1151 A reserved bit space mainly for purpose of padding 1152 and packing efficiency. 1153 1154 uchar 1155 1156 1157 HopSelector 1158 1159 The HopSelector produced by the prefix matching LFB, 1160 which will be output to downstream LFB to find next 1161 hop information. 1162 1163 uint32 1164 1165 1166 1167 1168 IPv4PrefixTableType 1169 1170 Data type for IPv4 longest prefix match table in 1171 IPv4UcastLPM LFB. Entry of the table is 1172 of IPv4PrefixInfoType data type. 1173 1174 1175 IPv4PrefixInfoType 1176 1177 1178 1179 IPv4UcastLPMStatsType 1180 1181 Data type for statistics in IPv4UcastLPM LFB. 1182 1183 1184 1185 InRcvdPkts 1186 Number of received input packets. 1187 uint64 1188 1189 1190 FwdPkts 1191 Number of forwarded packets. 1192 uint64 1193 1194 1195 NoRoutePkts 1196 1197 Number of packets with no route found. 1198 1199 uint64 1200 1201 1202 1203 1204 IPv6PrefixInfoType 1205 Data type for entry of IPv6 longest prefix match 1206 table in IPv6UcastLPM LFB. The destination IPv6 address 1207 of every input packet is used as a search key to look up 1208 the table to find out a next hop selector. 1209 1210 1211 IPv6Address 1212 The destination IPv6 address 1213 IPv6Addr 1214 1215 1216 Prefixlen 1217 The prefix length 1218 1219 uchar 1220 1221 1222 1223 1224 1225 1226 ECMPFlag 1227 ECMP flag 1228 1229 boolean 1230 1231 1232 False 1233 ECMP false 1234 1235 1236 True 1237 ECMP true 1238 1239 1240 1241 1242 1243 DefaultRouteFlag 1244 Default route flag 1245 1246 boolean 1247 1248 1249 False 1250 Default false 1251 1252 1253 True 1254 Default route true 1255 1256 1257 1258 1259 1260 Reserved 1261 1262 A reserved bit space mainly for purpose of padding 1263 and packing efficiency. 1264 1265 uchar 1266 1267 1268 HopSelector 1269 1270 The HopSelector produced by the prefix matching LFB, 1271 which will be output to downstream LFB to find next 1272 hop information. 1273 1274 uint32 1275 1276 1277 1278 1279 IPv6PrefixTableType 1280 1281 Data type for IPv6 longest prefix match table in 1282 IPv6UcastLPM LFB. Entry of the table is 1283 of IPv6PrefixInfoType data type. 1284 1285 1286 IPv6PrefixInfoType 1287 1288 1289 1290 IPv6UcastLPMStatsType 1291 Data type for statistics in IPv6UcastLPM LFB 1292 1293 1294 1295 InRcvdPkts 1296 Number of received input packets 1297 uint64 1298 1299 1300 FwdPkts 1301 Number of forwarded packets 1302 uint64 1303 1304 1305 NoRoutePkts 1306 1307 Number of packets with no route found. 1308 1309 uint64 1310 1311 1312 1313 1314 IPv4NextHopInfoType 1315 1316 Data type for entry of IPv4 next hop information table 1317 in IPv4NextHop LFB. The table uses a hop selector 1318 received from upstream LFB as a search key to look up 1319 index of the table to find the next hop information. 1320 1321 1322 1323 L3PortID 1324 1325 The ID of the logical output port that is to pass 1326 onto downstream LFB, indicating what port to the 1327 neighbor is as defined by L3. 1328 1329 uint32 1330 1331 1332 MTU 1333 1334 Maximum Transmission Unit for outgoing port 1335 1336 uint32 1337 1338 1339 NextHopIPAddr 1340 The next hop IPv4 address 1341 IPv4Addr 1342 1343 1344 MediaEncapInfoIndex 1345 1346 The index passed onto a downstream encapsulation 1347 LFB, used there as a search key to lookup further 1348 encapsulation information. 1349 1350 uint32 1351 1352 1353 LFBOutputSelectIndex 1354 1355 The index for the IPv4NextHop LFB to choose an 1356 instance in the group output port of the LFB to 1357 output. 1358 1359 uint32 1360 1361 1362 1363 1364 IPv4NextHopTableType 1365 1366 Data type for IPv4 next hop table in IPv4NextHop LFB. 1367 Entry of the table is of IPv4NextHopInfoType data type. 1368 1369 1370 IPv4NextHopInfoType 1371 1372 1373 1374 IPv6NextHopInfoType 1375 1376 Data type for entry of IPv6 next hop information table 1377 in IPv6NextHop LFB. The table uses a hop selector 1378 received from upstream LFB as a search key to look up 1379 index of the table to find the next hop information. 1380 1381 1382 1383 L3PortID 1384 1385 The ID of the logical output port that is to pass 1386 onto downstream LFB, indicating what port to the 1387 neighbor is as defined by L3. 1388 1389 uint32 1390 1391 1392 MTU 1393 1394 Maximum Transmission Unit for outgoing port 1395 1396 uint32 1397 1398 1399 NextHopIPAddr 1400 The next hop IPv6 address 1401 IPv6Addr 1402 1403 1404 MediaEncapInfoIndex 1405 1406 The index passed onto a downstream encapsulation 1407 LFB, used there as a search key to lookup further 1408 encapsulation information. 1409 1410 uint32 1411 1412 1413 LFBOutputSelectIndex 1414 1415 The index for the IPv6NextHop LFB to choose an instance 1416 in the group output port of the LFB to output. 1417 1418 uint32 1419 1420 1421 1422 1423 IPv6NextHopTableType 1424 1425 Data type for IPv6 next hop table in IPv6NextHop LFB. 1426 Entry of the table is of IPv6NextHopInfoType data type. 1427 1428 1429 IPv6NextHopInfoType 1430 1431 1432 1433 EncapTableEntryType 1434 1435 Data type for entry of Ethernet encapsulation table in 1436 EtherEncap LFB. The LFB uses the MediaEncapInfoIndex 1437 received from upstream LFB as index of the table to 1438 find encapsulation information of every packet. 1439 1440 1441 1442 DstMac 1443 1444 Destination MAC address for Ethernet encapsulation of 1445 the packet. 1446 1447 IEEEMAC 1448 1449 1450 SrcMac 1451 1452 Source MAC address for Ethernet encapsulation of the 1453 packet. 1454 1455 IEEEMAC 1456 1457 1458 VlanID 1459 The VLAN ID assigned to the packet 1460 VlanIDType 1461 1462 1463 Reserved 1464 1465 A reserved bit space mainly for purpose of padding 1466 and packing efficiency. 1467 1468 uint16 1469 1470 1471 L2PortID 1472 1473 The L2 logical output port ID for the packet. 1474 1475 uint32 1476 1477 1478 1479 1480 EncapTableType 1481 1482 Data type for Ethernet encapsulation table in Etherencap 1483 LFB. Entry of the table is of EncapTableEntryType data 1484 type. 1485 1486 1487 EncapTableEntryType 1488 1489 1490 1491 MetadataDispatchType 1492 1493 Data type for entry of metadata dispatch table used in 1494 BasicMetadataDispatch LFB. The LFB uses a metadata value 1495 as a search key to look up the table to find an index of 1496 the LFB group output port to output the packet. 1497 1498 1499 1500 MetadataValue 1501 The value of the dispatch metadata 1502 uint32 1503 1504 1505 OutputIndex 1506 1507 Index of a group output port for outgoing packets. 1509 1510 uint32 1511 1512 1513 1514 1515 MetadataDispatchTableType 1516 1517 Data type for metadata dispatch table used in 1518 BasicMetadataDispatch LFB. Metadata value of 1519 the table is also defined as a content key field. 1520 1521 1522 MetadataDispatchType 1523 1524 MetadataValue 1525 1526 1527 1528 1529 SchdDisciplineType 1530 Scheduling discipline type 1531 1532 uint32 1533 1534 1535 RR 1536 1537 Round Robin scheduling discipline 1538 1539 1540 1541 1542 1543 1544 QueueStatsType 1545 1546 Data type for entry of queue statistics table in 1547 GenericScheduler LFB. 1548 1549 1550 1551 QueueID 1552 The input queue ID 1553 uint32 1554 1555 1556 QueueDepthInPackets 1557 Current queue depth in packets 1558 uint32 1559 1560 1561 QueueDepthInBytes 1562 Current queue depth in bytes 1563 uint32 1564 1565 1566 1567 1568 QueueStatsTableType 1569 1570 Data type for queue statistics table in GenericScheduler 1571 LFB. Entry of the table is of QueueStatsType data type. 1572 1573 1574 QueueStatsType 1575 1576 1577 1578 1579 1580 PHYPortID 1581 Metadata indicating physical port ID 1582 1 1583 uint32 1584 1585 1586 SrcMAC 1587 Metadata indicating source MAC address 1588 2 1589 IEEEMAC 1590 1591 1592 DstMAC 1593 1594 Metadata indicating destination MAC address. 1595 1596 3 1597 IEEEMAC 1598 1599 1600 LogicalPortID 1601 Metadata of logical port ID 1602 4 1603 uint32 1604 1605 1606 EtherType 1607 Metadata indicating Ethernet type 1608 5 1609 uint16 1610 1611 1612 VlanID 1613 Metadata of VLAN ID 1614 6 1615 VlanIDType 1616 1617 1618 VlanPriority 1619 Metadata of VLAN priority 1620 7 1621 VlanPriorityType 1622 1623 1624 NextHopIPv4Addr 1625 1626 Metadata representing a next hop IPv4 address 1627 1628 8 1629 IPv4Addr 1630 1631 1632 NextHopIPv6Addr 1633 1634 Metadata representing a next hop IPv6 address 1635 1636 9 1637 IPv6Addr 1638 1639 1640 HopSelector 1641 Metadata indicating a hop selector 1642 10 1643 uint32 1644 1645 1646 ExceptionID 1647 1648 Metadata indicating exception types for exceptional cases 1649 during packet processing. 1650 1651 11 1652 1653 uint32 1654 1655 1656 AnyUnrecognizedExceptionCase 1657 Any unrecognized exception case 1658 1659 1660 ClassifyNoMatching 1661 1662 Exception case: no matching of tables in 1663 EtherClassifier LFB. 1664 1665 1666 1667 MediaEncapInfoIndexInvalid 1668 1669 Exception case: the MediaEncapInfoIndex value of 1670 the packet is invalid and cannot be allocated in 1671 the EncapTable in EtherEncap LFB. 1672 1673 1674 1675 EncapTableLookupFailed 1676 1677 Exception case: the packet fails lookup of the 1678 EncapTable table in EtherEncap LFB even though the 1679 MediaEncapInfoIndex is valid. 1680 1681 1682 1683 BadTTL 1684 1685 Exception case: packet with expired TTL 1686 1687 1688 1689 IPv4HeaderLengthMismatch 1690 1691 Exception case: packet with header length more 1692 than 5 words. 1693 1694 1695 1696 RouterAlertOptions 1697 1698 Exception case: packet IP head includes router 1699 alert options. 1700 1702 1703 1704 IPv6HopLimitZero 1705 1706 Exception case: packet with the hop limit to zero. 1707 1708 1709 1710 IPv6NextHeaderHBH 1711 1712 Exception case: packet with next header set to 1713 Hop-by-Hop. 1714 1715 1716 1717 SrcAddressExecption 1718 1719 Exception case: packet with exceptional source 1720 address. 1721 1722 1723 1724 DstAddressExecption 1725 1726 Exception case: packet with exceptional destination 1727 address. 1728 1729 1730 1731 LPMLookupFailed 1732 1733 Exception case: packet failed the LPM table lookup 1734 in a prefix match LFB. 1735 1736 1737 1738 HopSelectorInvalid 1739 1740 Exception case: HopSelector for the packet is 1741 invalid. 1742 1743 1744 1745 NextHopLookupFailed 1746 1747 Exception case: packet failed lookup of a next hop 1748 table even though HopSelector is valid. 1749 1751 1752 1753 FragRequired 1754 1755 Exception case: packet fragmentation is required 1756 1757 1758 1759 MetadataNoMatching 1760 1761 Exception case: there is no matching when looking 1762 up the metadata dispatch table in 1763 BasicMetadataDispatch LFB. 1764 1765 1766 1767 1768 1769 1770 ValidateErrorID 1771 1772 Metadata indicating error types when a packet passes 1773 validation process. 1774 1775 12 1776 1777 uint32 1778 1779 1780 AnyUnrecognizedValidateErrorCase 1781 1782 Any unrecognized validate error case. 1783 1784 1785 1786 InvalidIPv4PacketSize 1787 1788 Error case: packet length reported by the link 1789 layer is less than 20 bytes. 1790 1791 1792 1793 NotIPv4Packet 1794 1795 Error case: packet is not IP version 4 1796 1797 1798 InvalidIPv4HeaderLengthSize 1799 1800 Error case: packet with header length field in 1801 the header less than 5 words. 1802 1803 1804 1805 InvalidIPv4LengthFieldSize 1806 1807 Error case: packet with total length field in the 1808 header less than 20 bytes. 1809 1810 1811 1812 InvalidIPv4Checksum 1813 1814 Error case: packet with invalid checksum. 1815 1816 1817 1818 InvalidIPv4SrcAddr 1819 1820 Error case: packet with invalid IPv4 source 1821 address. 1822 1823 1824 1825 InvalidIPv4DstAddr 1826 1827 Error case: packet with invalid IPv4 destination 1828 address. 1829 1830 1831 1832 InvalidIPv6PacketSize 1833 1834 Error case: packet size is less than 40 bytes. 1835 1836 1837 1838 NotIPv6Packet 1839 1840 Error case: packet is not IP version 6 1841 1842 1843 1844 InvalidIPv6SrcAddr 1845 1846 Error case: packet with invalid IPv6 source address. 1848 1849 1850 1851 InvalidIPv6DstAddr 1852 1853 Error case: packet with invalid IPv6 destination 1854 address. 1855 1856 1857 1858 1859 1860 1861 L3PortID 1862 1863 Metadata indicating ID of an L3 logical port 1864 1865 13 1866 uint32 1867 1868 1869 RedirectIndex 1870 1871 Metadata that CE sends to RedirectIn LFB, indicating 1872 the index of the LFB group output port. 1873 1874 14 1875 uint32 1876 1877 1878 MediaEncapInfoIndex 1879 1880 A search key a packet uses to look up a table to select 1881 an encapsulation media. 1882 1883 15 1884 uint32 1885 1886 1887 1888 5. LFB Class Description 1890 According to ForCES specifications, LFB (Logical Function Block) is a 1891 well defined, logically separable functional block that resides in an 1892 FE, and is a functionally accurate abstraction of the FE's processing 1893 capabilities. An LFB Class (or type) is a template that represents a 1894 fine-grained, logically separable aspect of FE processing. Most LFBs 1895 are related to packet processing in the data path. LFB classes are 1896 the basic building blocks of the FE model. Note that [RFC5810] has 1897 already defined an 'FE Protocol LFB' which is a logical entity in 1898 each FE to control the ForCES protocol. [RFC5812] has already 1899 defined an 'FE Object LFB'. Information like the FE Name, FE ID, FE 1900 State, LFB Topology in the FE are represented in this LFB. 1902 As specified in Section 3.1, this document focuses on the base LFB 1903 library for implementing typical router functions, especially for IP 1904 forwarding functions. As a result, LFB classes in the library are 1905 all base LFBs to implement router forwarding. 1907 In this section, the terms "upstream LFB" and "downstream LFB" are 1908 used. These are used relative to an LFB to an LFB that is being 1909 described. An "upstream LFB" is one whose output ports are connected 1910 to input ports of the LFB under consideration such that output 1911 (typically packets with metadata) can be sent from the "upstream LFB" 1912 to the LFB under consideration. Similarly, a "downstream LFB" whose 1913 input ports are connected to output ports of the LFB under 1914 consideration such that the LFB under consideration can send 1915 information to the "downstream LFB". Note that in some rare 1916 topologies, an LFB may be both upstream and downstream relative to 1917 another LFB. 1919 Also note that, as a default provision of [RFC5812], in FE model, all 1920 metadata produced by upstream LFBs will pass through all downstream 1921 LFBs by default without being specified by input port or output port. 1922 Only those metadata that will be used (consumed) by an LFB will be 1923 explicitly marked in input of the LFB as expected metadata. For 1924 instance, in downstream LFBs of a physical layer LFB, even there is 1925 no specific metadata expected, metadata like PHYPortID produced by 1926 the physical layer LFB will always pass through all downstream LFBs 1927 regardless of whether the metadata has been expected by the LFBs or 1928 not. 1930 5.1. Ethernet Processing LFBs 1932 As the most popular physical and data link layer protocols, Ethernet 1933 is widely deployed. It becomes a basic requirement for a router to 1934 be able to process various Ethernet data packets. 1936 Note that there exist different versions of Ethernet formats, like 1937 Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP. 1938 There also exist varieties of LAN techniques based on Ethernet, like 1939 various VLANs, MACinMAC, etc. Ethernet processing LFBs defined here 1940 are intended to be able to cope with all these variations of Ethernet 1941 technology. 1943 There are also various types of Ethernet physical interface media. 1944 Among them, copper and fiber media may be the most popular ones. As 1945 a base LFB definition and a starting point, the document only defines 1946 an Ethernet physical LFB with copper media. For other media 1947 interfaces, specific LFBs may be defined in the future versions of 1948 the library. 1950 5.1.1. EtherPHYCop 1952 EtherPHYCop LFB abstracts an Ethernet interface physical layer with 1953 media limited to copper. 1955 5.1.1.1. Data Handling 1957 This LFB is the interface to the Ethernet physical media. The LFB 1958 handles Ethernet frames coming in from or going out of the FE. 1959 Ethernet frames sent and received cover all packets encapsulated with 1960 different versions of Ethernet protocols, like Ethernet V2, 802.3 1961 RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets 1962 encapsulated with varieties of LAN techniques based on Ethernet, like 1963 various VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll 1964 frame type has been introduced. 1966 Ethernet frames are received from the physical media port and passed 1967 downstream to LFBs such as EtherMACIn via a singleton output known as 1968 "EtherPHYOut". A 'PHYPortID' metadata, to indicate which physical 1969 port the frame came into from the external world, is passed along 1970 with the frame. 1972 Ethernet packets are received by this LFB from upstream LFBs such as 1973 EtherMacOut LFBs via the singleton input known as "EtherPHYIn" before 1974 being sent out onto the external world. 1976 5.1.1.2. Components 1978 The AdminStatus component is defined for CE to administratively 1979 manage the status of the LFB. The CE may administratively startup or 1980 shutdown the LFB by changing the value of AdminStatus. The default 1981 value is set to 'Down'. 1983 An OperStatus component captures the physical port operational 1984 status. A PHYPortStatusChanged event is defined so the LFB can 1985 report to the CE whenever there is an operational status change of 1986 the physical port. 1988 The PHYPortID component is a unique identification for a physical 1989 port. It is defined as 'read-only' by CE. Its value is enumerated 1990 by FE. The component will be used to produce a 'PHYPortID' metadata 1991 at the LFB output and to associate it to every Ethernet packet this 1992 LFB receives. The metadata will be handed to downstream LFBs for 1993 them to use the PHYPortID. 1995 A group of components are defined for link speed management. The 1996 AdminLinkSpeed is for CE to configure link speed for the port and the 1997 OperLinkSpeed is for CE to query the actual link speed in operation. 1998 The default value for the AdminLinkSpeed is set to auto-negotiation 1999 mode. 2001 A group of components are defined for duplex mode management. The 2002 AdminDuplexMode is for CE to configure proper duplex mode for the 2003 port and the OperDuplexMode is for CE to query the actual duplex mode 2004 in operation. The default value for the AdminDuplexMode is set to 2005 auto-negotiation mode. 2007 A CarrierStatus component captures the status of the carrier and 2008 specifies whether the port link is operationally up. The default 2009 value for the CarrierStatus is 'false'. 2011 5.1.1.3. Capabilities 2013 The capability information for this LFB includes the link speeds that 2014 are supported by the FE (SupportedLinkSpeed) as well as the supported 2015 duplex modes (SupportedDuplexMode). 2017 5.1.1.4. Events 2019 Several events are generated. There is an event for changes in the 2020 status of the physical port (PhyPortStatusChanged). Such an event 2021 will notify that the physical port status has been changed and the 2022 report will include the new status of the physical port. 2024 Another event captures changes in the operational link speed 2025 (LinkSpeedChanged). Such an event will notify the CE that the 2026 operational speed has been changed and the report will include the 2027 new negotiated operational speed. 2029 A final event captures changes in the duplex mode 2030 (DuplexModeChanged). Such an event will notify the CE that the 2031 duplex mode has been changed and the report will include the new 2032 negotiated duplex mode. 2034 5.1.2. EtherMACIn 2036 EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. 2037 This LFB describes Ethernet processing functions like MAC address 2038 locality check, deciding if the Ethernet packets should be bridged, 2039 providing Ethernet layer flow control, etc. 2041 5.1.2.1. Data Handling 2043 The LFB is expected to receive all types of Ethernet packets, via a 2044 singleton input known as "EtherPktsIn", which are usually output from 2045 some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside 2046 with a metadata indicating the physical port ID that the packet 2047 arrived on. 2049 The LFB is defined with two separate singleton outputs. All Output 2050 packets are emitted in the original Ethernet format received at the 2051 physical port, unchanged, and cover all types of Ethernet types. 2053 The first singleton output is known as "NormalPathOut". It usually 2054 outputs Ethernet packets to some LFB like an EtherClassifier LFB for 2055 further L3 forwarding process alongside with a PHYPortID metadata 2056 indicating which physical port the packet came from. 2058 The second singleton output is known as "L2BridgingPathOut". 2059 Although the LFB library this document defines is basically to meet 2060 typical router functions, it will attempt to be forward compatible 2061 with future router functions. The "L2BridgingPathOut" is defined to 2062 meet the requirement that L2 bridging functions may be optionally 2063 supported simultaneously with L3 processing and some L2 bridging LFBs 2064 that may be defined in the future. If the FE supports L2 bridging, 2065 the CE can enable or disable it by means of a "L2BridgingPathEnable" 2066 component in the FE. If it is enabled, by also instantiating some L2 2067 bridging LFB instances following the L2BridgingPathOut, FEs are 2068 expected to fulfill L2 bridging functions. L2BridgingPathOut will 2069 output packets exactly the same as that in the NormalPathOut output. 2071 This LFB can be set to work in a Promiscuous Mode, allowing all 2072 packets to pass through the LFB without being dropped. Otherwise, a 2073 locality check will be performed based on the local MAC addresses. 2074 All packets that do not pass through the locality check will be 2075 dropped. 2077 This LFB can optionally participate in Ethernet flow control in 2078 cooperation with EtherMACOut LFB. This document does not go into the 2079 details of how this is implemented. This document also does not 2080 describe how the buffers which induce the flow control messages 2081 behave - it is assumed that such artifacts exist and describing them 2082 is out of scope in this document. 2084 5.1.2.2. Components 2086 The AdminStatus component is defined for the CE to administratively 2087 manage the status of the LFB. The CE may administratively startup or 2088 shutdown the LFB by changing the value of AdminStatus. The default 2089 value is set to 'Down'. 2091 The LocalMACAddresses component specifies the local MAC addresses 2092 based on which locality checks will be made. This component is an 2093 array of MAC addresses, and of 'read-write' access permission. 2095 An L2BridgingPathEnable component captures whether the LFB is set to 2096 work as a L2 bridge. An FE that does not support bridging will 2097 internally set this flag to false, and additionally set the flag 2098 property as read-only. The default value for the component is 2099 'false'. 2101 The PromiscuousMode component specifies whether the LFB is set to 2102 work as in a promiscuous mode. The default value for the component 2103 is 'false'. 2105 The TxFlowControl component defines whether the LFB is performing 2106 flow control on sending packets. The default value is 'false'. Note 2107 that the component is defined as "optional". If an FE does not 2108 implement the component while a CE try to configure the component to 2109 this FE, an error from FE may be responded to CE with error code 2110 like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or 0x15(E_NOT_SUPPORTED) 2111 depending on the FE processing. See [RFC5810] for details. 2113 The RxFlowControl component defines whether the LFB is performing 2114 flow control on receiving packets. The default value is 'false'.The 2115 component is also defined as "optional" one. 2117 A struct component, MACInStats, defines a set of statistics for this 2118 LFB, including the number of received packets and the number of 2119 dropped packets. Note that this statistics component is optional to 2120 implementers. If a CE tries to query the componennt while it is not 2121 implemented in an FE, an error code will be responded to CE 2122 indicating the error type like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or 2123 0x15(E_NOT_SUPPORTED), depending on the FE implementation. 2125 5.1.2.3. Capabilities 2127 This LFB does not have a list of capabilities. 2129 5.1.2.4. Events 2131 This LFB does not have any events specified. 2133 5.1.3. EtherClassifier 2135 EtherClassifier LFB abstracts the process to decapsulate Ethernet 2136 packets and then classify them. 2138 5.1.3.1. Data Handling 2140 This LFB describes the process of decapsulating Ethernet packets and 2141 classifying them into various network layer data packets according to 2142 information included in the Ethernet packets headers. 2144 The LFB is expected to receive all types of Ethernet packets, via a 2145 singleton input known as "EtherPktsIn", which are usually output from 2146 an upstream LFB like EtherMACIn LFB. This input is also capable of 2147 multiplexing to allow for multiple upstream LFBs being connected. 2148 For instance, when L2 bridging function is enabled in EtherMACIn LFB, 2149 some L2 bridging LFBs may be applied. In this case, some Ethernet 2150 packets after L2 processing may have to be input to EtherClassifier 2151 LFB for classification, while simultaneously packets directly output 2152 from EtherMACIn may also need to input to this LFB. This input is 2153 capable of handling such a case. Usually, all expected Ethernet 2154 Packets will be associated with a PHYPortID metadata, indicating the 2155 physical port the packet comes from. In some cases, for instance, 2156 like in a MACinMAC case, a LogicalPortID metadata may be expected to 2157 associate with the Ethernet packet to further indicate which logical 2158 port the Ethernet packet belongs to. Note that PHYPortID metadata is 2159 always expected while LogicalPortID metadata is optionally expected. 2161 Two output LFB ports are defined. 2163 The first output is a group output port known as "ClassifyOut". 2164 Types of network layer protocol packets are output to instances of 2165 the port group. Because there may be various type of protocol 2166 packets at the output ports, the produced output frame is defined as 2167 arbitrary for the purpose of wide extensibility in the future. 2168 Metadata to be carried along with the packet data is produced at this 2169 LFB for consumption by downstream LFBs. The metadata passed 2170 downstream includes PHYPortID, as well as information on Ethernet 2171 type, source MAC address, destination MAC address and the logical 2172 port ID. If the original packet is a VLAN packet and contains a VLAN 2173 ID and a VLAN priority value, then the VLAN ID and the VLAN priority 2174 value are also carried downstream as metadata. As a result, the VLAN 2175 ID and priority metadata are defined with the availability of 2176 "conditional". 2178 The second output is a singleton output port known as "ExceptionOut", 2179 which will output packets for which the data processing failed, along 2180 with an additional ExceptionID metadata to indicate what caused the 2181 exception. Currently defined exception types include: 2183 o There is no matching when classifying the packet. 2185 Usually the exception out port may point to no where, indicating 2186 packets with exceptions are dropped, while in some cases, the output 2187 may be pointed to the path to the CE for further processing, 2188 depending on individual implementations. 2190 5.1.3.2. Components 2192 An EtherDispatchTable array component is defined in the LFB to 2193 dispatch every Ethernet packet to the output group according to the 2194 logical port ID assigned by the VlanInputTable to the packet and the 2195 Ethernet type in the Ethernet packet header. Each row of the array 2196 is a struct containing a Logical Port ID, an EtherType and an Output 2197 Index. With the CE configuring the dispatch table, the LFB can be 2198 expected to classify various network layer protocol type packets and 2199 output them at different output ports. It is expected that the LFB 2200 classify packets according to protocols like IPv4, IPv6, MPLS, ARP, 2201 ND, etc. 2203 A VlanInputTable array component is defined in the LFB to classify 2204 VLAN Ethernet packets. Each row of the array is a struct containing 2205 an Incoming Port ID, a VLAN ID and a Logical Port ID. According to 2206 IEEE VLAN specifications, all Ethernet packets can be recognized as 2207 VLAN types by defining that if there is no VLAN encapsulation in a 2208 packet, a case with VLAN tag 0 is considered. Every input packet is 2209 assigned with a new LogicalPortID according to the packet incoming 2210 port ID and the VLAN ID. A packet incoming port ID is defined as a 2211 logical port ID if a logical port ID is associated with the packet, 2212 or a physical port ID if no logical port ID associated. The VLAN ID 2213 is exactly the VLAN ID in the packet if it is a VLAN packet, or 0 if 2214 it is not. Note that a logical port ID of a packet may be rewritten 2215 with a new one by the VlanInputTable processing. 2217 Note that the logical port ID and physical port ID mentioned above 2218 are all originally configured by CE, and are globally effective 2219 within a ForCES NE (Network Element). To distinguish a physical port 2220 ID from a logical port ID in the incoming port ID field of the 2221 VlanInputTable, physical port ID and logical port ID must be assigned 2222 with separate number spaces. 2224 An array component, EtherClassifyStats, defines a set of statistics 2225 for this LFB, measuring the number of packets per EtherType. Each 2226 row of the array is a struct containing an EtherType and a Packet 2227 number.Note that this statistics component is optional to 2228 implementers. 2230 5.1.3.3. Capabilities 2232 This LFB does not have a list of capabilities. 2234 5.1.3.4. Events 2236 This LFB has no events specified. 2238 5.1.4. EtherEncap 2240 The EtherEncap LFB abstracts the process to replace or attach 2241 appropriate Ethernet headers to the packet. 2243 5.1.4.1. Data Handling 2245 This LFB abstracts the process of encapsulating Ethernet headers onto 2246 received packets. The encapsulation is based on passed metadata. 2248 The LFB is expected to receive IPv4 and IPv6 packets, via a singleton 2249 input port known as "EncapIn" which may be connected to an upstream 2250 LFB like an IPv4NextHop, an IPv6NextHop, BasicMetadataDispatch, or 2251 any LFB which requires to output packets for Ethernet encapsulation. 2252 The LFB always expects from upstream LFBs the MediaEncapInfoIndex 2253 metadata which is used as a search key to lookup the encapsulation 2254 table EncapTable by the search key matching the table index. An 2255 input packet may also optionally receive a VLAN priority metadata, 2256 indicating that the packet is originally with a priority value. The 2257 priority value will be loaded back to the packet when encapsulating. 2258 The optional VLAN priority metadata is defined with a default value 2259 0. 2261 Two singleton output LFB ports are defined. 2263 The first singleton output known as "SuccessOut". Upon a successful 2264 table lookup, the destination and source MAC addresses, and the 2265 logical media port (L2PortID) are found in the matching table entry. 2266 The CE may set the VlanID in case VLANs are used. By default the 2267 table entry for VlanID of 0 is used as per IEEE rules. Whatever the 2268 value of VlanID is, if the input metadata VlanPriority is non-zero, 2269 the packet will have a VLAN tag. If the VlanPriority and the VlanID 2270 are all zero, there is no VLAN tag to this packet. After replacing 2271 or attaching the appropriate Ethernet headers to the packet is 2272 complete, the packet is passed out on the "SuccessOut" LFB port to a 2273 downstream LFB instance alongside with the L2PortID. 2275 The second singleton output known as "ExceptionOut", which will 2276 output packets for which the table lookup fails, along with an 2277 additional ExceptionID metadata. Currently defined exception types 2278 only include the following case: 2280 o The MediaEncapInfoIndex value of the packet is invalid and can not 2281 be allocated in the EncapTable. 2283 o The packet failed lookup of the EncapTable table even though the 2284 MediaEncapInfoIndex is valid. 2286 The upstream LFB may be programmed by the CE to pass along a 2287 MediaEncapInfoIndex that does not exist in the EncapTable. That is 2288 to allow for resolution of the L2 headers, if needed, to be made at 2289 the L2 encapsulation level in this case (Ethernet) via ARP, or ND (or 2290 other methods depending on the link layer technology) when a table 2291 miss occurs. 2293 For neighbor L2 header resolution(table miss exception), the 2294 processing LFB may pass this packet to the CE via the redirect LFB or 2295 FE software or another LFB instance for further resolution. In such 2296 a case the metadata NextHopIPv4Addr or NextHopIPv6Addr generated by 2297 next hop LFB is also passed to the exception handling. Such an IP 2298 address could be used to do activities such as ARP or ND by the 2299 handler it is passed to. 2301 The result of the L2 resolution is to update the EncapTable as well 2302 as the next hop LFB so subsequent packets do not fail EncapTable 2303 lookup. The EtherEncap LFB does not make any assumptions of how the 2304 EncapTable is updated by the CE (or whether ARP/ND is used 2305 dynamically or static maps exist). 2307 Downstream LFB instances could be either an EtherMACOut type or a 2308 BasicMetadataDispatch type. If the final packet L2 processing is 2309 possible to be on per-media-port basis or resides on a different FE 2310 or in cases where L2 header resolution is needed, then the model 2311 makes sense to use a BasicMetadataDispatch LFB to fan out to 2312 different LFB instances. If there is a direct egress port point, 2313 then the model makes sense to have a downstream LFB instance being an 2314 EtherMACOut. 2316 5.1.4.2. Components 2318 This LFB has only one component named EncapTable which is defined as 2319 an array. Each row of the array is a struct containing the 2320 destination MAC address, the source MAC address, the VLAN ID with a 2321 default value of zero and the output logical L2 port ID. 2323 5.1.4.3. Capabilities 2325 This LFB does not have a list of capabilities. 2327 5.1.4.4. Events 2329 This LFB does not have any events specified. 2331 5.1.5. EtherMACOut 2333 EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. 2334 This LFB describes Ethernet packet output process. Ethernet output 2335 functions are closely related to Ethernet input functions, therefore 2336 many components defined in this LFB are as aliases of EtherMACIn LFB 2337 components. 2339 5.1.5.1. Data Handling 2341 The LFB is expected to receive all types of Ethernet packets, via a 2342 singleton input known as "EtherPktsIn", which are usually output from 2343 an Ethernet encapsulation LFB, alongside with a metadata indicating 2344 the physical port ID that the packet will go through. 2346 The LFB is defined with a singleton output port known as 2347 "EtherPktsOut". All Output packets are in Ethernet format, possibly 2348 with various Ethernet types, alongside with a metadata indicating the 2349 physical port ID the packet is to go through. This output links to a 2350 downstream LFB that is usually an Ethernet physical LFB like 2351 EtherPHYcop LFB. 2353 This LFB can optionally participate in Ethernet flow control in 2354 cooperation with EtherMACIn LFB. This document does not go into the 2355 details of how this is implemented. This document also does not 2356 describe how the buffers which induce the flow control messages 2357 behave - it is assumed that such artifacts exist and describing them 2358 is out of scope in this document. 2360 Note that as a base definition, functions like multiple virtual MAC 2361 layers are not supported in this LFB version. It may be supported in 2362 the future by defining a subclass or a new version of this LFB. 2364 5.1.5.2. Components 2366 The AdminStatus component is defined for CE to administratively 2367 manage the status of the LFB. The CE may administratively startup or 2368 shutdown the LFB by changing the value of AdminStatus. The default 2369 value is set to 'Down'. Note that this component is defined as an 2370 alias of the AdminStatus component in the EtherMACIn LFB. This 2371 infers that an EtherMACOut LFB usually coexists with an EtherMACIn 2372 LFB, both of which share the same administrative status management by 2373 CE. Alias properties as defined in the ForCES FE model [RFC5812] 2374 will be used by CE to declare the target component this alias refers, 2375 which include the target LFB class and instance IDs as well as the 2376 path to the target component. 2378 The MTU component defines the maximum transmission unit. 2380 The optinal TxFlowControl component defines whether the LFB is 2381 performing flow control on sending packets. The default value is 2382 'false'. Note that this component is defined as an alias of 2383 TxFlowControl component in the EtherMACIn LFB. 2385 The optional RxFlowControl component defines whether the LFB is 2386 performing flow control on receiving packets. The default value is 2387 'false'. Note that this component is defined as an alias of 2388 RxFlowControl component in the EtherMACIn LFB. 2390 A struct component, MACOutStats, defines a set of statistics for this 2391 LFB, including the number of transmitted packets and the number of 2392 dropped packets. This statistics component is optional to 2393 impleneters. 2395 5.1.5.3. Capabilities 2397 This LFB does not have a list of capabilities. 2399 5.1.5.4. Events 2401 This LFB does not have any events specified. 2403 5.2. IP Packet Validation LFBs 2405 The LFBs are defined to abstract IP packet validation process. An 2406 IPv4Validator LFB is specifically for IPv4 protocol validation and an 2407 IPv6Validator LFB for IPv6. 2409 5.2.1. IPv4Validator 2411 The IPv4Validator LFB performs IPv4 packets validation. 2413 5.2.1.1. Data Handling 2415 This LFB performs IPv4 validation according to [RFC1812] and its 2416 updates. The IPv4 packet will be output to the corresponding LFB 2417 port the indication whether the packet is unicast, multicast or 2418 whether an exception has occurred or the validation failed. 2420 This LFB always expects, as input, packets which have been indicated 2421 as IPv4 packets by an upstream LFB, like an EtherClassifier LFB. 2422 There is no specific metadata expected by the input of the LFB. 2424 Four output LFB ports are defined. 2426 All validated IPv4 unicast packets will be output at the singleton 2427 port known as "IPv4UnicastOut". All validated IPv4 multicast packets 2428 will be output at the singleton port known as "IPv4MulticastOut" 2429 port. 2431 A singleton port known as "ExceptionOut" is defined to output packets 2432 which have been validated as exception packets. An exception ID 2433 metadata is produced to indicate what has caused the exception. An 2434 exception case is the case when a packet needs further processing 2435 before being normally forwarded. Currently defined exception types 2436 include: 2438 o Packet with expired TTL 2440 o Packet with header length more than 5 words 2442 o Packet IP head including Router Alert options 2444 o Packet with exceptional source address 2446 o Packet with exceptional destination address 2448 Note that although TTL is checked in this LFB for validity, 2449 operations like TTL decrement are made by the downstream forwarding 2450 LFB. 2452 The final singleton port known as "FailOut" is defined for all 2453 packets which have errors and failed the validation process. An 2454 error case is the case when a packet is unable to be further 2455 processed nor forwarded except being dropped. An error ID is 2456 associated a packet to indicate the failure reason. Currently 2457 defined failure reasons include: 2459 o Packet with size reported less than 20 bytes 2461 o Packet with version is not IPv4 2463 o Packet with header length less than 5 words 2465 o Packet with total length field less than 20 bytes 2467 o Packet with invalid checksum 2469 o Packet with invalid source address 2471 o Packet with invalid destination address 2473 5.2.1.2. Components 2475 This LFB has only one struct component, the 2476 IPv4ValidatorStatisticsType, which defines a set of statistics for 2477 validation process, including the number of bad header packets, the 2478 number of bad total length packets, the number of bad TTL packets, 2479 and the number of bad checksum packets. This statistics componennt 2480 is optional to implementers. 2482 5.2.1.3. Capabilities 2484 This LFB does not have a list of capabilities 2486 5.2.1.4. Events 2488 This LFB does not have any events specified. 2490 5.2.2. IPv6Validator 2492 The IPv6Validator LFB performs IPv6 packets validation. 2494 5.2.2.1. Data Handling 2496 This LFB performs IPv6 validation according to [RFC2460] and its 2497 updates. Then the IPv6 packet will be output to the corresponding 2498 port regarding of the validation result, whether the packet is a 2499 unicast or a multicast one, an exception has occurred or the 2500 validation failed. 2502 This LFB always expects, as input, packets which have been indicated 2503 as IPv6 packets by an upstream LFB, like an EtherClassifier LFB. 2504 There is no specific metadata expected by the input of the LFB. 2506 Similar to the IPv4validator LFB, IPv6Validator LFB has also defined 2507 four output ports to emit packets with various validation results. 2509 All validated IPv6 unicast packets will be output at the singleton 2510 port known as "IPv6UnicastOut". All validated IPv6 multicast packets 2511 will be output at the singleton port known as "IPv6MulticastOut" 2512 port. There is no metadata produced at this LFB. 2514 A singleton port known as "ExceptionOut" is defined to output packets 2515 which have been validated as exception packets. An exception case is 2516 the case when a packet needs further processing before being normally 2517 forwarded. An exception ID metadata is produced to indicate what 2518 caused the exception. Currently defined exception types include: 2520 o Packet with hop limit to zero 2522 o Packet with next header set to Hop-by-Hop 2524 o Packet with exceptional source address 2526 o Packet with exceptional destination address 2528 The final singleton port known as "FailOut" is defined for all 2529 packets which have errors and failed the validation process. An 2530 error case is the case when a packet is unable to be further 2531 processed nor forwarded except being dropped. A validate error ID is 2532 associated to every failed packet to indicate the reason. Currently 2533 defined reasons include: 2535 o Packet with size reported less than 40 bytes 2537 o Packet with not IPv6 version 2539 o Packet with invalid source address 2541 o Packet with invalid destination address 2543 Note that in the base type library, definitions for exception ID and 2544 validate error ID metadata are applied to both IPv4Validator and 2545 IPv6Validator LFBs, i.e., the two LFBs share the same medadata 2546 definition, with different ID assignment inside. 2548 5.2.2.2. Components 2550 This LFB has only one struct component, the 2551 IPv6ValidatorStatisticsType, which defines a set of statistics for 2552 validation process, including the number of bad header packets, the 2553 number of bad total length packets, and the number of bad hop limit 2554 packets. Note that this component is optional to implementers. 2556 5.2.2.3. Capabilities 2558 This LFB does not have a list of capabilities 2560 5.2.2.4. Events 2562 This LFB does not have any events specified. 2564 5.3. IP Forwarding LFBs 2566 IP Forwarding LFBs are specifically defined to abstract the IP 2567 forwarding processes. As definitions for a base LFB library, this 2568 document restricts its LFB definition scope only to IP unicast 2569 forwarding. IP multicast may be defined in future documents. 2571 The two fundamental tasks performed in IP unicast forwarding 2572 constitute looking up the forwarding information table to find next 2573 hop information, and then using the resulting next hop details to 2574 forward packets out on specific physical output ports. This document 2575 models the forwarding processes by abstracting out the described two 2576 steps. Whereas this document describes functional LFB models which 2577 are modular, there may be multiple ways to implement the abstracted 2578 models. It is not intended nor expected that the provided LFB models 2579 constrain implementations. 2581 Based on the IP forwarding abstraction, two kind of typical IP 2582 unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next 2583 hop application LFB. They are further distinguished by IPv4 and IPv6 2584 protocols. 2586 5.3.1. IPv4UcastLPM 2588 The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match 2589 (LPM) process. 2591 This LFB also provides facilities to support users to implement 2592 equal-cost multi-path routing (ECMP) or reverse path forwarding 2593 (RPF). However, this LFB itself does not provide ECMP or RPF. To 2594 fully implement ECMP or RPF, additional specific LFBs, like a 2595 specific ECMP LFB or an RPF LFB, will have to be defined. 2597 5.3.1.1. Data Handling 2599 This LFB performs the IPv4 unicast LPM table looking up. It always 2600 expects as input IPv4 unicast packets from one singleton input known 2601 as "PktsIn". Then the LFB uses the destination IPv4 address of every 2602 packet as search key to look up the IPv4 prefix table and generate a 2603 hop selector as the matching result. The hop selector is passed as 2604 packet metadata to downstream LFBs, and will usually be used there as 2605 a search index to find more next hop information. 2607 Three singleton output LFB ports are defined. 2609 The first singleton output known as "NormalOut" outputs IPv4 unicast 2610 packets that succeed the LPM lookup and (got a hop selector). The 2611 hop selector is associated with the packet as a metadata. Downstream 2612 from the LPM LFB is usually a next hop application LFB, like an 2613 IPv4NextHop LFB. 2615 The second singleton output known as "ECMPOut" is defined to provide 2616 support for users wishing to implement ECMP. 2618 An ECMP flag is defined in the LPM table to enable the LFB to support 2619 ECMP. When a table entry is created with the flag set true, it 2620 indicates this table entry is for ECMP only. A packet, which has 2621 passed through this prefix lookup, will always output from "ECMPOut" 2622 output port, with the hop selector being its lookup result. The 2623 output will usually directly go to a downstream ECMP processing LFB, 2624 where the hop selector can usually further generate optimized one or 2625 multiple next hop routes by use of ECMP algorithms. 2627 A default route flag is defined in the LPM table to enable the LFB to 2628 support a default route as well as loose RPF. When this flag is set 2629 true, the table entry is identified a default route which also 2630 implies that the route is forbidden for RPF. If a user wants to 2631 implement RPF on FE, a specific RPF LFB will have to be defined. In 2632 such RPF LFB, a component can be defined as an alias of the prefix 2633 table component of this LFB as described below. 2635 The final singleton output is known as "ExceptionOut" and is defined 2636 to allow exception packets to output here, along with an ExceptionID 2637 metadata to indicate what caused the exception. Currently defined 2638 exception types include: 2640 o The packet failed the LPM lookup of the prefix table. 2642 The upstream LFB of this LFB is usually IPv4Validator LFB. If RPF is 2643 to be adopted, the upstream can be an RPF LFB, when defined. 2645 The downstream LFB is usually IPv4NextHop LFB. If ECMP is adopted, 2646 the downstream can be an ECMP LFB, when defined. 2648 5.3.1.2. Components 2650 This LFB has two components. 2652 The IPv4PrefixTable component is defined as an array component of the 2653 LFB. Each row of the array contains an IPv4 address, a Prefix 2654 length, a Hop Selector, an ECMP flag and a Default Route flag. The 2655 LFB uses the destination IPv4 address of every input packet as search 2656 key to look up this table in order extract a next hop selector. The 2657 ECMP flag is for the LFB to support ECMP. The default route flag is 2658 for the LFB to support a default route and for loose RPF. 2660 The IPv4UcastLPMStats component is a struct component which collects 2661 statistics information, including the total number of input packets 2662 received, the IPv4 packets forwarded by this LFB and the number of IP 2663 datagrams discarded due to no route found.Note the component is 2664 defined as optional to implementers. 2666 5.3.1.3. Capabilities 2668 This LFB does not have a list of capabilities 2670 5.3.1.4. Events 2672 This LFB does not have any events specified. 2674 5.3.2. IPv4NextHop 2676 This LFB abstracts the process of selecting ipv4 next hop action. 2678 5.3.2.1. Data Handling 2680 The LFB abstracts the process of next hop information application to 2681 IPv4 packets. It receives an IPv4 packet with an associated next hop 2682 identifier (HopSelector), and uses the identifier as a table index to 2683 look up a next hop table to find an appropriate LFB output port. 2685 The LFB is expected to receive unicast IPv4 packets, via a singleton 2686 input known as "PktsIn" along with a HopSelector metadata which is 2687 used as a table index to lookup the NextHop table. The data 2688 processing involves the forwarding TTL decrement and IP checksum 2689 recalculation. 2691 Two output LFB ports are defined. 2693 The first output is a group output port known as "SuccessOut". On 2694 successful data processing the packet is sent out an LFB-port from 2695 within the LFB port group as selected by the LFBOutputSelectIndex 2696 value of the matched table entry. The packet is sent to a downstream 2697 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. 2699 The second output is a singleton output port known as "ExceptionOut", 2700 which will output packets for which the data processing failed, along 2701 with an additional ExceptionID metadata to indicate what caused the 2702 exception. Currently defined exception types include: 2704 o The HopSelector for the packet is invalid. 2706 o The packet failed lookup of the next hop table even though the 2707 HopSelector is valid. 2709 o The MTU for outgoing interface is less than the packet size. 2711 Downstream LFB instances could be either a BasicMetadataDispatch type 2712 (Section 5.5.1), used to fan out to different LFB instances or a 2713 media encapsulation related type, such as an EtherEncap type or a 2714 RedirectOut type(Section 5.4.2). For example, if there are Ethernet 2715 and other tunnel Encapsulation, then a BasicMetadataDispatch LFB can 2716 use the L3PortID metadata (Section 5.3.2.2) to dispatch packets to 2717 different encapsulator. 2719 5.3.2.2. Components 2721 This LFB has only one component named IPv4NextHopTable which is 2722 defined as an array. The HopSelector received is used to match the 2723 array index of IPv4NextHopTable to find out a row of the table as the 2724 next hop information result. Each row of the array is a struct 2725 containing: 2727 o The L3PortID, which is the ID of the Logical Output Port that is 2728 passed onto the downstream LFB instance. This ID indicates what 2729 port to the neighbor is as defined by L3. Usually this ID is used 2730 for the next hop LFB to distinguish packets that need different L2 2731 encapsulating. For instance, some packets may require general 2732 Ethernet encapsulation while others may require various types of 2733 tunnel encapsulations. In such case, different L3PortIDs are 2734 assigned to the packets and are as metadata passed to downstream 2735 LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be 2736 applied as the downstream LFB so as to dispatch packets to 2737 different encapsulation LFB instances according to the L3PortIDs. 2739 o MTU, the Maximum Transmission Unit for the outgoing port. 2741 o NextHopIPAddr, the IPv4 next hop address. 2743 o MediaEncapInfoIndex, the index we pass onto the downstream 2744 encapsulation LFB instance and that is used there as a search key 2745 to lookup a table (typically media encapsulation related) for 2746 further encapsulation information. The search key looks up the 2747 table by matching the table index.Note that an encapsulation LFB 2748 instance may not directly follow the next hop LFB, but the index 2749 is passed as a metadata associated, as such an encapsulation LFB 2750 instance even further downstream to the next hop LFB can still use 2751 the index. In some cases, depending on implementation, the CE may 2752 set the MediaEncapInfoIndex passed downstream to a value that will 2753 fail lookup when it gets to a target encapsulation LFB; such a 2754 lookup failure at that point is an indication that further 2755 resolution is needed. For an example of this approach refer to 2756 Section 7.2 which talks about ARP and mentions this approach. 2758 o LFBOutputSelectIndex, the LFB Group output port index to select 2759 downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's 2760 table LFBTopology (See [RFC5812]) component FromPortIndex 2761 corresponding to the port group mapping FromLFBID as IPv4NextHop 2762 LFB instance. 2764 5.3.2.3. Capabilities 2766 This LFB does not have a list of capabilities 2768 5.3.2.4. Events 2770 This LFB does not have any events specified. 2772 5.3.3. IPv6UcastLPM 2774 The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match 2775 (LPM) process. The definition of this LFB is similar to the 2776 IPv4UcastLPM LFB except that all IP addresses refer to IPv6 2777 addresses. 2779 This LFB also provides facilities to support users to implement 2780 equal-cost multi-path routing (ECMP) or reverse path forwarding 2781 (RPF). However, this LFB itself does not provide ECMP or RPF. To 2782 fully implement ECMP or RPF, additional specific LFBs, like a 2783 specific ECMP LFB or an RPF LFB, will have to be defined. This work 2784 may be done in the future version of the document. 2786 5.3.3.1. Data Handling 2788 This LFB performs the IPv6 unicast LPM table look up. It always 2789 expects as input IPv6 unicast packets from one singleton input known 2790 as "PktsIn". The destination IPv6 address of an incoming packet is 2791 used as search key to look up the IPv6 prefix table and generate a 2792 hop selector. This hop selector result is associated to the packet 2793 as a metadata and sent to downstream LFBs, and will usually be used 2794 in downstream LFBs as a search key to find more next hop information. 2796 Three singleton output LFB ports are defined. 2798 The first singleton output known as "NormalOut" outputs IPv6 unicast 2799 packets that succeed the LPM lookup (and got a hop selector). The 2800 hop selector is associated with the packet as a metadata. Downstream 2801 from the LPM LFB is usually a next hop application LFB, like an 2802 IPv6NextHop LFB. 2804 The second singleton output known as "ECMPOut" is defined to provide 2805 support for users wishing to implement ECMP. 2807 An ECMP flag is defined in the LPM table to enable the LFB to support 2808 ECMP. When a table entry is created with the flag set true, it 2809 indicates this table entry is for ECMP only. A packet, which has 2810 passed through this prefix lookup, will always output from "ECMPOut" 2811 output port, with the hop selector being its lookup result. The 2812 output will usually directly go to a downstream ECMP processing LFB, 2813 where the hop selector can usually further generate optimized one or 2814 multiple next hop routes by use of ECMP algorithms. 2816 A default route flag is defined in the LPM table to enable the LFB to 2817 support a default route as well as loose RPF. When this flag is set 2818 true, the table entry is identified a default route which also 2819 implies that the route is forbidden for RPF. 2821 If a user wants to implement RPF on FE, a specific RPF LFB will have 2822 to be defined. In such RPF LFB, a component can be defined as an 2823 alias of the prefix table component of this LFB as described below. 2825 The final singleton output is known as "ExceptionOut" and is defined 2826 to allow exception packets to output here, along with an ExceptionID 2827 metadata to indicate what caused the exception. Currently defined 2828 exception types include: 2830 o The packet failed the LPM lookup of the prefix table. 2832 The upstream LFB of this LFB is usually IPv6Validator LFB. If RPF is 2833 to be adopted, the upstream can be an RPF LFB, when defined. 2835 The downstream LFB is usually an IPv6NextHop LFB. If ECMP is 2836 adopted, the downstream can be an ECMP LFB, when defined. 2838 5.3.3.2. Components 2840 This LFB has two components. 2842 The IPv6PrefixTable component is defined as an array component of the 2843 LFB. Each row of the array contains an IPv6 address, a Prefix 2844 length, a Hop Selector, an ECMP flag and a Default Route flag. The 2845 ECMP flag is so the LFB can support ECMP. The default route flag is 2846 for the LFB to support a default route and for loose RPF as described 2847 earlier. 2849 The IPv6UcastLPMStats component is a struct component which collects 2850 statistics information, including the total number of input packets 2851 received, the IPv6 packets forwarded by this LFB and the number of IP 2852 datagrams discarded due to no route found.Note the component is 2853 defined as optional to implementers. 2855 5.3.3.3. Capabilities 2857 This LFB does not have a list of capabilities 2859 5.3.3.4. Events 2861 This LFB does not have any events specified. 2863 5.3.4. IPv6NextHop 2865 This LFB abstracts the process of selecting IPv6 next hop action. 2867 5.3.4.1. Data Handling 2869 The LFB abstracts the process of next hop information application to 2870 IPv6 packets. It receives an IPv6 packet with an associated next hop 2871 identifier (HopSelector), and uses the identifier to look up a next 2872 hop table to find an appropriate output port from the LFB. 2874 The LFB is expected to receive unicast IPv6 packets, via a singleton 2875 input known as "PktsIn" along with a HopSelector metadata which is 2876 used as a table index to lookup the next hop table. 2878 Two output LFB ports are defined. 2880 The first output is a group output port known as "SuccessOut". On 2881 successful data processing the packet is sent out an LFB port from 2882 within the LFB port group as selected by the LFBOutputSelectIndex 2883 value of the matched table entry. The packet is sent to a downstream 2884 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. 2886 The second output is a singleton output port known as "ExceptionOut", 2887 which will output packets for which the data processing failed, along 2888 with an additional ExceptionID metadata to indicate what caused the 2889 exception. Currently defined exception types include: 2891 o The HopSelector for the packet is invalid. 2893 o The packet failed lookup of the next hop table even though the 2894 HopSelector is valid. 2896 o The MTU for outgoing interface is less than the packet size. 2898 Downstream LFB instances could be either a BasicMetadataDispatch 2899 type, used to fan out to different LFB instances or a media 2900 encapsulatation related type, such as an EtherEncap type or a 2901 RedirectOut type. For example, when the downstream LFB is 2902 BasicMetadataDispatch, and there exist Ethernet and other tunnel 2903 Encapsulation downstream from BasicMetadataDispatch, then the 2904 BasicMetadataDispatch LFB can use the L3PortID metadata (See section 2905 below) to dispatch packets to the different encapsulator LFBs. 2907 5.3.4.2. Components 2909 This LFB has only one component named IPv6NextHopTable which is 2910 defined as an array. The array index of IPv6NextHopTable is used for 2911 a HopSelector to find out a row of the table as the next hop 2912 information. Each row of the array is a struct containing: 2914 o The L3PortID, which is the ID of the Logical Output Port that is 2915 passed onto the downstream LFB instance. This ID indicates what 2916 port to the neighbor is as defined by L3. Usually this ID is used 2917 for the next hop LFB to distinguish packets that need different L2 2918 encapsulating. For instance, some packets may require general 2919 Ethernet encapsulation while others may require various types of 2920 tunnel encapsulations. In such case, different L3PortIDs are 2921 assigned to the packets and are as metadata passed to downstream 2922 LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be 2923 applied as the downstream LFB so as to dispatch packets to 2924 different encapsulation LFB instances according to the L3PortIDs. 2926 o MTU, the Maximum Transmission Unit for the outgoing port. 2928 o NextHopIPAddr, the IPv6 next hop address. 2930 o MediaEncapInfoIndex, the index we pass onto the downstream 2931 encapsulation LFB instance and that is used there as a search key 2932 to lookup a table (typically media encapsulation related) for 2933 further encapsulation information. The saearch key looks up the 2934 table by matching the table index. Note that an encapsulation LFB 2935 instance may not directly follow the next hop LFB, but the index 2936 is passed as a metadata associated, as such an encapsulation LFB 2937 instance even further downstream to the next hop LFB can still use 2938 the index. In some cases, depending on implementation, the CE may 2939 set the MediaEncapInfoIndex passed downstream to a value that will 2940 fail lookup when it gets to a target encapsulation LFB; such a 2941 lookup failure at that point is an indication that further 2942 resolution is needed. For an example of this approach refer to 2943 Section 7.2 which talks about ARP and mentions this approach. 2945 o LFBOutputSelectIndex, the LFB Group output port index to select 2946 downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's 2947 table LFBTopology (See [RFC5812]) component FromPortIndex 2948 corresponding to the port group mapping FromLFBID as IPv4NextHop 2949 LFB instance. 2951 5.3.4.3. Capabilities 2953 This LFB does not have a list of capabilities 2955 5.3.4.4. Events 2957 This LFB does not have any events specified. 2959 5.4. Redirect LFBs 2961 Redirect LFBs abstract data packets transportation process between CE 2962 and FE. Some packets output from some LFBs may have to be delivered 2963 to CE for further processing, and some packets generated by CE may 2964 have to be delivered to FE and further to some specific LFBs for data 2965 path processing. According to [RFC5810], data packets and their 2966 associated metadata are encapsulated in ForCES redirect message for 2967 transportation between CE and FE. We define two LFBs to abstract the 2968 process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an LFB 2969 topology of an FE, only one RedirectIn LFB instance and one 2970 RedirectOut LFB instance exist. 2972 5.4.1. RedirectIn 2974 RedirectIn LFB abstracts the process for the CE to inject data 2975 packets into the FE data path. 2977 5.4.1.1. Data Handling 2979 A RedirectIn LFB abstracts the process for the CE to inject data 2980 packets into the FE LFB topology so as to input data packets into FE 2981 data paths. From LFB topology point of view, the RedirectIn LFB acts 2982 as a source point for data packets coming from CE, therefore 2983 RedirectIn LFB is defined with a single output LFB port (and no input 2984 LFB port). 2986 The single output port of RedirectIn LFB is defined as a group output 2987 type, with the name of "PktsOut". Packets produced by this output 2988 will have arbitrary frame types decided by the CE which generated the 2989 packets. Possible frames may include IPv4, IPv6, or ARP protocol 2990 packets. The CE may associate some metadata to indicate the frame 2991 types and may also associate other metadata to indicate various 2992 information on the packets. Among them, there MUST exist a 2993 'RedirectIndex' metadata, which is an integer acting as an index. 2994 When the CE transmits the metadata along with the packet to a 2995 RedirectIn LFB, the LFB will read the RedirectIndex metadata and 2996 output the packet to one of its group output port instance, whose 2997 port index is indicated by this metadata. Any other metadata, in 2998 addition to 'RedirectIndex', will be passed untouched along the 2999 packet delivered by the CE to downstream LFB. This means the 3000 'RedirectIndex' metadata from CE will be "consumed" by the RedirectIn 3001 LFB and will not be passed to downstream LFB. Note that, a packet 3002 from CE without a 'RedirectIndex' metadata associated will be dropped 3003 by the LFB. Note that all metadata visible to the LFB need to be 3004 global and IANA controlled. See the "IANA Considerations" of the 3005 document for more details, where a metadata ID private space that can 3006 be used by vendors is also provided. 3008 5.4.1.2. Components 3010 An optional statistics component is defined to collect the number of 3011 packets received by the LFB from CE. There are no other components 3012 defined for current version of the LFB. 3014 5.4.1.3. Capabilities 3016 This LFB does not have a list of capabilities 3018 5.4.1.4. Events 3020 This LFB does not have any events specified. 3022 5.4.2. RedirectOut 3024 RedirectOut LFB abstracts the process for LFBs in the FE to deliver 3025 data packets to the CE. 3027 5.4.2.1. Data Handling 3029 A RedirectOut LFB abstracts the process for LFBs in the FE to deliver 3030 data packets to the CE. From the LFB's topology point of view, the 3031 RedirectOut LFB acts as a sink point for data packets going to the 3032 CE, therefore RedirectOut LFB is defined with a single input LFB port 3033 (and no output LFB port). 3035 The RedirectOut LFB has only one singleton input known as "PktsIn", 3036 but is capable of receiving packets from multiple LFBs by 3037 multiplexing this input. The input expects any kind of frame type 3038 therefore the frame type has been specified as arbitrary, and also 3039 all types of metadata are expected. All associated metadata produced 3040 (but not consumed) by previous processed LFBs should be delivered to 3041 CE via the ForCES protocol redirect message [RFC5810]. The CE can 3042 decide on how to process the redirected packet by referencing the 3043 associated metadata. As an example, a packet could be redirected by 3044 the FE to the CE because the EtherEncap LFB is not able to resolve L2 3045 information. The metadata "ExceptionID", created by the EtherEncap 3046 LFB is passed along with the packet and should be sufficient for the 3047 CE to do the necessary processing and resolve the L2 entry required. 3048 Note that all metadata visible to the LFB need to be global and IANA 3049 controlled. See the "IANA Considerations" of the document for more 3050 details, where a metadata ID private space that can be used by 3051 vendors is also provided. 3053 5.4.2.2. Components 3055 An optional statistics component is defined to collect the number of 3056 packets sent by the LFB to CE. There are no other components defined 3057 for current version of the LFB. 3059 5.4.2.3. Capabilities 3061 This LFB does not have a list of capabilities 3063 5.4.2.4. Events 3065 This LFB does not have any events specified. 3067 5.5. General Purpose LFBs 3069 5.5.1. BasicMetadataDispatch 3071 The BasicMetadataDispatch LFB is defined to abstract the process in 3072 which a packet is dispatched to some output path based on its 3073 associated metadata value. 3075 5.5.1.1. Data Handling 3077 The BasicMetadataDispatch has only one singleton input known as 3078 "PktsIn". Every input packet should be associated with a metadata 3079 that will be used by the LFB to do the dispatch. This LFB contains a 3080 metadata ID and a dispatch table named MetadataDispatchTable, all 3081 configured by the CE. The metadata ID specifies which metadata is to 3082 be used for dispatching packets. The MetadataDispatchTable contains 3083 entries of a metadata value and an OutputIndex, specifying that the 3084 packet with the metadata value must go out from the LFB group output 3085 port instance with the OutputIndex. 3087 Two output LFB ports are defined. 3089 The first output is a group output port known as "PktsOut". A packet 3090 with its associated metadata having found an OutputIndex by 3091 successfully looking up the dispatch table will be output to the 3092 group port instance with the corresponding index. 3094 The second output is a singleton output port known as "ExceptionOut", 3095 which will output packets for which the data processing failed, along 3096 with an additional ExceptionID metadata to indicate what caused the 3097 exception. Currently defined exception types only include one case: 3099 o There is no matching when looking up the metadata dispatch table. 3101 As an example, if the CE decides to dispatch packets according to a 3102 physical port ID (PHYPortID), the CE may set the ID of PHYPortID 3103 metadata to the LFB first. Moreover, the CE also sets the PHYPortID 3104 actual values (the metadata values) and assigned OutputIndex for the 3105 values to the dispatch table in the LFB. When a packet arrives, a 3106 PHYPortID metadata is found associated with the packet, the metadata 3107 value is further used as a key to look up the dispatch table to find 3108 out an output port instance for the packet. 3110 Currently the BasicMetadataDispatch LFB only allows the metadata 3111 value of the dispatch table entry be 32-bits integer. A metadata 3112 with other types of value is not supported in this version. A more 3113 complex metadata dispatch LFB may be defined in future version of the 3114 library. In that LFB, multiple tuples of metadata with more value 3115 types supported may be used to dispatch packets. 3117 5.5.1.2. Components 3119 This LFB has two components. One component is MetadataID and the 3120 other is MetadataDispatchTable. Each row entry of the dispatch table 3121 is a struct containing metadata value and the OutputIndex. Note that 3122 currently, the metadata value is only allowed to be 32-bits integer. 3124 The metadata value is also defined as a content key for the table. 3125 The concept of content key is a searching key for tables which is 3126 defined in the ForCES FE Model [RFC5812]. With the content key, CE 3127 can manipulate the table by means of a specific metadata value rather 3128 than by the table index only. See [RFC5812] document and also the 3129 ForCES Protocol [RFC5810] for more details on the definition and use 3130 of a content key. 3132 5.5.1.3. Capabilities 3134 This LFB does not have a list of capabilities 3136 5.5.1.4. Events 3138 This LFB does not have any events specified. 3140 5.5.2. GenericScheduler 3142 This is a preliminary generic scheduler LFB for abstracting a simple 3143 scheduling process. 3145 5.5.2.1. Data Handling 3147 There exist various kinds of scheduling strategies with various 3148 implementations. As a base LFB library, this document only defines a 3149 preliminary generic scheduler LFB for abstracting a simple scheduling 3150 process. Users may use this LFB as a basic LFB to further construct 3151 more complex scheduler LFBs by means of "inheritance" as described in 3152 [RFC5812]. 3154 Packets of any arbitrary frame type are received via a group input 3155 known as "PktsIn" with no additional metadata expected. This group 3156 input is capable of multiple input port instances. Each port 3157 instance may be connected to different upstream LFB output. Inside 3158 the LFB, it is abstracted that each input port instance is connected 3159 to a queue, and the queue is marked with a queue ID whose value is 3160 exactly the same as the index of corresponding group input port 3161 instance. Scheduling disciplines are applied to all queues and also 3162 all packets in the queues.The group input port property 3163 PortGroupLimits in ObjectLFB as defined by ForCES FE model[RFC5810] 3164 provides means for the CE to query the capability of total queue 3165 numbers the scheduler supports. The CE can then decide how many 3166 queues it may use for a scheduling application. 3168 Scheduled packets are output from a singleton output port of the LFB 3169 knows as "PktsOut" with no corresponding metadata. 3171 More complex scheduler LFBs may be defined with more complex 3172 scheduling disciplines by succeeding this LFB. For instance, a 3173 priority scheduler LFB may be defined by inheriting this LFB and 3174 defining a component to indicate priorities for all input queues. 3176 5.5.2.2. Components 3178 The SchedulingDiscipline component is for the CE to specify a 3179 scheduling discipline to the LFB. Currently defined scheduling 3180 disciplines only include Round Robin (RR) strategy. The default 3181 scheduling discipline is RR then. 3183 The QueueStats component is defined to allow CE to query every queue 3184 status of the scheduler. It is an array component and each row of 3185 the array is a struct containing a queue ID. Currently defined queue 3186 status includes the queue depth in packets and the queue depth in 3187 bytes. Using the queue ID as the index, the CE can query every queue 3188 for its used length in unit of packets or bytes.Note that the 3189 QueueStats componennt is defined as optional to implementers. 3191 5.5.2.3. Capabilities 3193 The following capability is currently defined for the 3194 GenericScheduler. 3196 o The queue length limit providing the storage ability for every 3197 queue. 3199 5.5.2.4. Events 3201 This LFB does not have any events specified. 3203 6. XML for LFB Library 3205 3206 3209 3210 3211 3212 EtherPHYCop 3213 3214 The EtherPHYCop LFB describes an Ethernet interface 3215 which limits the physical media to copper. 3216 3217 1.0 3218 3219 3220 EtherPHYIn 3221 3222 The input port of the EtherPHYCop LFB. It expects any 3223 type of Ethernet frame. 3224 3225 3226 3227 EthernetAll 3228 3229 3230 3231 3232 3233 3234 EtherPHYOut 3235 3236 The output port of the EtherPHYCop LFB. The output 3237 packet has the same Ethernet frame type with the 3238 input packet, associated with a metadata indicating 3239 the ID of the physical port. 3240 3241 3242 3243 EthernetAll 3244 3245 3246 PHYPortID 3247 3248 3249 3251 3252 3253 3254 PHYPortID 3255 3256 The identification of the physical port 3257 3258 uint32 3259 3260 3261 AdminStatus 3262 3263 The port status administratively requested 3264 3265 PortStatusType 3266 2 3267 3268 3269 OperStatus 3270 3271 The port actual operational status 3272 3273 PortStatusType 3274 3275 3276 AdminLinkSpeed 3277 3278 The port link speed administratively requested 3279 3280 LANSpeedType 3281 LAN_SPEED_AUTO 3282 3283 3284 OperLinkSpeed 3285 3286 The port actual operational link speed 3287 3288 LANSpeedType 3289 3290 3291 AdminDuplexMode 3292 3293 The port duplex mode administratively requested 3294 3295 DuplexType 3296 Auto 3297 3298 3299 OperDuplexMode 3300 3301 The port actual operational duplex mode 3302 3303 DuplexType 3304 3305 3306 CarrierStatus 3307 The carrier status of the port 3308 boolean 3309 false 3310 3311 3312 3313 3314 SupportedLinkSpeed 3315 3316 A list of link speeds the port supports 3317 3318 3319 LANSpeedType 3320 3321 3322 3323 SupportedDuplexMode 3324 3325 A list of duplex modes the port supports 3326 3327 3328 DuplexType 3329 3330 3331 3332 3333 3334 PHYPortStatusChanged 3335 3336 An event reporting change on operational status of the 3337 physical port. 3338 3339 3340 OperStatus 3341 3342 3343 3344 3345 OperStatus 3346 3348 3349 3350 3351 LinkSpeedChanged 3352 3353 An event reporting change on operational link speed 3354 of the physical port. 3355 3356 3357 OperLinkSpeed 3358 3359 3360 3361 3362 OperLinkSpeed 3363 3364 3365 3366 3367 DuplexModeChanged 3368 3369 An event reporting change on operational duplex mode 3370 of the physical port. 3371 3372 3373 OperDuplexMode 3374 3375 3376 3377 3378 OperDuplexMode 3379 3380 3381 3382 3383 3384 3385 EtherMACIn 3386 3387 EtherMACIn LFB describes an Ethernet port at MAC data link 3388 layer. The LFB describes Ethernet processing functions 3389 of MAC address locality check, deciding if the Ethernet 3390 packets should be bridged, providing Ethernet layer flow 3391 control, etc. 3392 3393 1.0 3394 3395 3396 EtherPktsIn 3397 3398 The input port of the EtherMACIn LFB. It expects any 3399 type of Ethernet frame. 3400 3401 3402 3403 EthernetAll 3404 3405 3406 PHYPortID 3407 3408 3409 3410 3411 3412 3413 NormalPathOut 3414 3415 An output port in the EtherMACIn LFB. It outputs 3416 Ethernet packets to downstream LFBs for normal 3417 processing like Ethernet packet classification and 3418 other L3 IP layer processing. 3419 3420 3421 3422 EthernetAll 3423 3424 3425 PHYPortID 3426 3427 3428 3429 3430 L2BridgingPathOut 3431 3432 An output port in 3433 the EtherMACIn LFB. It outputs Ethernet packets 3434 to downstream LFBs for layer 2 bridging processing. 3435 The port is switched on or off by the 3436 L2BridgingPathEnable flag in the LFB. 3437 3438 3439 3440 EthernetAll 3441 3442 3443 PHYPortID 3445 3446 3447 3448 3449 3450 3451 AdminStatus 3452 3453 The LFB status administratively requested, which has 3454 the same data type with a port status. Default is in 3455 'down' status. 3456 3457 PortStatusType 3458 2 3459 3460 3461 LocalMACAddresses 3462 3463 Local MAC address(es) of the Ethernet port the LFB 3464 represents. 3465 3466 3467 IEEEMAC 3468 3469 3470 3471 L2BridgingPathEnable 3472 3473 A flag indicating if the LFB L2 BridgingPath output 3474 port is enabled or not. Default is not enabled. 3475 3476 boolean 3477 false 3478 3479 3480 PromiscuousMode 3481 3482 A flag indicating whether the LFB is in promiscuous 3483 mode or not. Default is not. 3484 3485 boolean 3486 false 3487 3488 3489 TxFlowControl 3490 3491 A flag indicating whether transmit flow control is 3492 applied or not. Default is not. 3494 3495 3496 boolean 3497 false 3498 3499 3500 RxFlowControl 3501 3502 A flag indicating whether receive flow control is 3503 applied or not. Default is not. 3504 3505 3506 boolean 3507 false 3508 3509 3510 MACInStats 3511 3512 The statistics of the EtherMACIn LFB 3513 3514 3515 MACInStatsType 3516 3517 3518 3519 3520 EtherClassifier 3521 3522 EtherClassifier LFB describes the process to decapsulate 3523 Ethernet packets and then classify them into various 3524 network layer packets according to information in the 3525 Ethernet headers. It is expected the LFB classifies packets 3526 by packet types like IPv4, IPv6, MPLS, ARP, ND, etc. 3527 3528 1.0 3529 3530 3531 EtherPktsIn 3532 3533 Input port of Ethernet packets. PHYPortID metadata is 3534 always expected while LogicalPortID metadata is 3535 optionally expected to associate with every input 3536 Ethernet packet. 3537 3538 3539 3540 EthernetAll 3541 3542 3543 PHYPortID 3544 3545 LogicalPortID 3546 3547 3548 3549 3550 3551 3552 ClassifyOut 3553 3554 A group port for output of Ethernet classifying 3555 results. 3556 3557 3558 3559 Arbitrary 3560 3561 3562 PHYPortID 3563 SrcMAC 3564 DstMAC 3565 EtherType 3566 VlanID 3567 VlanPriority 3568 3569 3570 3571 3572 ExceptionOut 3573 3574 A singleton port for output of all Ethernet packets 3575 that fail the classifying process. An ExceptionID 3576 metadata indicates the failure reason. 3577 3578 3579 3580 Arbitrary 3581 3582 3583 ExceptionID 3584 3585 3586 3587 3588 3589 3590 EtherDispatchTable 3591 3592 An EtherDispatchTable array component which is defined 3593 in the LFB to dispatch every Ethernet packet to output 3594 ports according to logical port ID assigned by the 3595 VlanInputTable in the LFB and Ethernet type in the 3596 Ethernet packet header. 3597 3598 EtherDispatchTableType 3599 3600 3601 VlanInputTable 3602 3603 A VlanInputTable array component which is defined in 3604 the LFB to classify VLAN Ethernet packets. Every input 3605 packet is assigned with a new LogicalPortID according 3606 to the packet incoming port ID and VLAN ID. 3607 3608 VlanInputTableType 3609 3610 3611 EtherClassifyStats 3612 3613 A table recording statistics on the Ethernet 3614 classifying process in the LFB. 3615 3616 3617 EtherClassifyStatsTableType 3618 3619 3620 3621 3622 EtherEncap 3623 3624 The EtherEncap LFB abstracts the process of encapsulating 3625 Ethernet headers onto received packets. The encapsulation 3626 is based on passed metadata. 3627 3628 1.0 3629 3630 3631 EncapIn 3632 3633 A input port receiving IPv4 and/or IPv6 packets for 3634 encapsulation. A MediaEncapInfoIndex metadata is 3635 expected and a VLAN priority metadata is optionally 3636 expected with every input packet. 3637 3638 3639 3640 IPv4 3641 IPv6 3642 3643 3644 MediaEncapInfoIndex 3645 3646 VlanPriority 3647 3648 3649 3650 3651 3652 3653 SuccessOut 3654 3655 An output port for packets which have found Ethernet 3656 L2 information and have been successfully encapsulated 3657 into an Ethernet packet. A L2portID metadata is 3658 produced for every output packet. 3659 3660 3661 3662 IPv4 3663 IPv6 3664 3665 3666 L2PortID 3667 3668 3669 3670 3671 ExceptionOut 3672 3673 An output port for packets that fail encapsulation 3674 in the LFB. An ExceptionID metadata indicates failure 3675 reason. 3676 3677 3678 3679 IPv4 3680 IPv6 3681 3682 3683 ExceptionID 3684 MediaEncapInfoIndex 3685 VlanPriority 3687 3688 3689 3690 3691 3692 3693 EncapTable 3694 3695 An array table for Ethernet encapsulation information 3696 lookup. Each row of the array contains destination MAC 3697 address, source MAC address, VLAN ID, and output 3698 logical L2 port ID. 3699 3700 EncapTableType 3701 3702 3703 3704 3705 EtherMACOut 3706 3707 EtherMACOut LFB abstracts an Ethernet port at MAC data link 3708 layer. It specifically describes Ethernet packet process 3709 for output to physical port. A downstream LFB is usually an 3710 Ethernet physical LFB like EtherPHYcop LFB. Note that 3711 Ethernet output functions are closely related to Ethernet 3712 input functions, therefore some components defined in this 3713 LFB are as alias of EtherMACIn LFB. 3714 3715 1.0 3716 3717 3718 EtherPktsIn 3719 3720 The input port of the EtherMACOut LFB. It expects any 3721 type of Ethernet frame. 3722 3723 3724 3725 EthernetAll 3726 3727 3728 PHYPortID 3729 3730 3731 3732 3733 3734 3735 EtherPktsOut 3736 3737 A port to output all Ethernet packets, each with a 3738 metadata indicating the physical port ID the packet 3739 is to go. 3740 3741 3742 3743 EthernetAll 3744 3745 3746 PHYPortID 3747 3748 3749 3750 3751 3752 3753 AdminStatus 3754 3755 The LFB status administratively requested, which has 3756 the same data type with a port status. The component 3757 is defined as alias of AdminStatus component in 3758 EtherMACIn LFB. 3759 3760 PortStatusType 3761 3762 3763 MTU 3764 Maximum transmission unit (MTU) 3765 uint32 3766 3767 3768 TxFlowControl 3769 3770 A flag indicating whether transmit flow control is 3771 applied, defined as alias of TxFlowControl component 3772 in EtherMACIn LFB. 3773 3774 3775 boolean 3776 3777 3778 RxFlowControl 3779 3780 A flag indicating whether receive flow control is 3781 applied, defined as alias of RxFlowControl component 3782 in EtherMACIn LFB. 3784 3785 3786 boolean 3787 3788 3789 MACOutStats 3790 3791 The statistics of the EtherMACOut LFB 3792 3793 3794 MACOutStatsType 3795 3796 3797 3798 3799 IPv4Validator 3800 3801 This LFB performs IPv4 validation according to RFC1812 and 3802 its updates. The IPv4 packet will be output to the 3803 corresponding LFB port, indicating whether the packet is 3804 unicast, multicast or whether an exception has occurred or 3805 the validation failed. 3806 3807 1.0 3808 3809 3810 ValidatePktsIn 3811 3812 Input port for data packets to be validated 3813 3814 3815 3816 Arbitrary 3817 3818 3819 3820 3821 3822 3823 IPv4UnicastOut 3824 3825 Output port for validated IPv4 unicast packets 3826 3827 3828 3829 IPv4Unicast 3830 3831 3833 3834 3835 IPv4MulticastOut 3836 3837 Output port for validated IPv4 multicast packets 3838 3839 3840 3841 IPv4Multicast 3842 3843 3844 3845 3846 ExceptionOut 3847 3848 Output port for all packets with exceptional cases 3849 when validating. An ExceptionID metadata indicates 3850 the exception case type. 3851 3852 3853 3854 IPv4 3855 3856 3857 ExceptionID 3858 3859 3860 3861 3862 FailOut 3863 3864 Output port for packets failed validating process. 3865 A ValidateErrorID metadata indicates the error type 3866 or failure reason. 3867 3868 3869 3870 IPv4 3871 3872 3873 ValidateErrorID 3874 3875 3876 3877 3878 3879 3880 IPv4ValidatorStats 3881 3882 The statistics information for validating process in 3883 the LFB. 3884 3885 3886 IPv4ValidatorStatsType 3887 3888 3889 3890 3891 IPv6Validator 3892 3893 This LFB performs IPv6 validation according to RFC2460 and 3894 its updates. Then the IPv6 packet will be output to the 3895 corresponding port, indicating whether the packet is a 3896 unicast or a multicast one, an exception has occurred or 3897 the validation failed. 3898 3899 1.0 3900 3901 3902 ValidatePktsIn 3903 3904 Input port for data packets to be validated 3905 3906 3907 3908 Arbitrary 3909 3910 3911 3912 3913 3914 3915 IPv6UnicastOut 3916 3917 Output port for validated IPv6 unicast packets 3918 3919 3920 3921 IPv6Unicast 3922 3923 3924 3925 3926 IPv6MulticastOut 3927 3928 Output port for validated IPv6 multicast packets 3930 3931 3932 3933 IPv6Multicast 3934 3935 3936 3937 3938 ExceptionOut 3939 3940 Output port for packets with exceptional cases when 3941 validating. An ExceptionID metadata indicates the 3942 exception case type. 3943 3944 3945 3946 IPv6 3947 3948 3949 ExceptionID 3950 3951 3952 3953 3954 FailOut 3955 3956 Output port for packets failed validating process. 3957 A ValidateErrorID metadata indicates the error type 3958 or failure reason. 3959 3960 3961 3962 IPv6 3963 3964 3965 ValidateErrorID 3966 3967 3968 3969 3970 3971 3972 IPv6ValidatorStats 3973 3974 The statistics information for validating process in 3975 the LFB. 3976 3977 3978 IPv6ValidatorStatsType 3979 3980 3981 3982 3983 IPv4UcastLPM 3984 3985 The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest 3986 Prefix Match (LPM) process. This LFB supports to implement 3987 equal-cost multi-path routing (ECMP) and reverse path 3988 forwarding (RPF). 3989 3990 1.0 3991 3992 3993 PktsIn 3994 3995 A port for input of packets to be processed. IPv4 3996 unicast packets are expected. 3997 3998 3999 4000 IPv4Unicast 4001 4002 4003 4004 4005 4006 4007 NormalOut 4008 4009 An output port to output IPv4 unicast packets 4010 successfully passed the LPM lookup. A HopSelector 4011 metadata is produced to associate every output packet 4012 for downstream LFB to do next hop action. 4013 4014 4015 4016 IPv4Unicast 4017 4018 4019 HopSelector 4020 4021 4022 4023 4024 ECMPOut 4025 4026 The port to output packets needing further ECMP 4027 processing. A downstream ECMP processing LFB is usually 4028 followed to the port. If ECMP is not required, no 4029 downstream LFB may be connected to the port. 4030 4031 4032 4033 IPv4Unicast 4034 4035 4036 HopSelector 4037 4038 4039 4040 4041 ExceptionOut 4042 4043 The port to output all packets with exceptional cases 4044 happened during LPM process. An ExceptionID metadata 4045 is associated to indicate what caused the exception. 4046 4047 4048 4049 IPv4Unicast 4050 4051 4052 ExceptionID 4053 4054 4055 4056 4057 4058 4059 IPv4PrefixTable 4060 4061 A table for IPv4 Longest Prefix Match(LPM). The 4062 destination IPv4 address of every input packet is 4063 used as a search key to look up the table to find 4064 out a next hop selector. 4065 4066 IPv4PrefixTableType 4067 4068 4069 IPv4UcastLPMStats 4070 4071 The statistics information for the IPv4 unicast LPM 4072 process in the LFB. 4073 4074 4075 IPv4UcastLPMStatsType 4076 4077 4078 4079 4080 IPv6UcastLPM 4081 4082 The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest 4083 Prefix Match (LPM) process. This LFB supports to implement 4084 equal-cost multi-path routing (ECMP) and reverse path 4085 forwarding (RPF). 4086 4087 1.0 4088 4089 4090 PktsIn 4091 4092 A port for input of packets to be processed. IPv6 4093 unicast packets are expected. 4094 4095 4096 4097 IPv6Unicast 4098 4099 4100 4101 4102 4103 4104 NormalOut 4105 4106 An output port to output IPv6 unicast packets 4107 successfully passed the LPM lookup. A HopSelector 4108 metadata is produced to associate every output packet 4109 for downstream LFB to do next hop action. 4110 4111 4112 4113 IPv6Unicast 4114 4115 4116 HopSelector 4117 4118 4119 4120 4121 ECMPOut 4122 4123 The port to output packets needing further ECMP 4124 processing. A downstream ECMP processing LFB is usually 4125 followed to the port. If ECMP is not required, no 4126 downstream LFB may be connected to the port. 4127 4128 4129 4130 IPv6Unicast 4131 4132 4133 HopSelector 4134 4135 4136 4137 4138 ExceptionOut 4139 4140 The port to output all packets with exceptional cases 4141 happened during LPM process. An ExceptionID metadata 4142 is associated to indicate what caused the exception. 4143 4144 4145 4146 IPv6Unicast 4147 4148 4149 ExceptionID 4150 4151 4152 4153 4154 4155 4156 IPv6PrefixTable 4157 4158 A table for IPv6 Longest Prefix Match(LPM). The 4159 destination IPv6 address of every input packet is 4160 used as a search key to look up the table to find 4161 out a next hop selector. 4162 4163 IPv6PrefixTableType 4164 4165 4166 IPv6UcastLPMStats 4167 4168 The statistics information for the IPv6 unicast LPM 4169 process in the LFB. 4171 4172 4173 IPv6UcastLPMStatsType 4174 4175 4176 4177 4178 IPv4NextHop 4179 4180 The IPv4NextHop LFB abstracts the process of next hop 4181 information application to IPv4 packets. It receives an IPv4 4182 packet with an associated next hop identifier (HopSelector), 4183 uses the identifier as a table index to look up a next hop 4184 table to find an appropriate output port. The data 4185 processing also involves the forwarding TTL decrement and 4186 IP checksum recalculation. 4187 4188 1.0 4189 4190 4191 PktsIn 4192 4193 A port for input of unicast IPv4 packets, along with 4194 a HopSelector metadata. 4195 4196 4197 4198 IPv4Unicast 4199 4200 4201 HopSelector 4202 4203 4204 4205 4206 4207 4208 SuccessOut 4209 4210 The group port for output of packets who successfully 4211 found next hop information. Some metadata are 4212 associated with every packet. 4213 4214 4215 4216 IPv4Unicast 4217 4218 4219 L3PortID 4220 NextHopIPv4Addr 4221 4222 MediaEncapInfoIndex 4223 4224 4225 4226 4227 ExceptionOut 4228 4229 The output port for packets with exceptional or 4230 failure case. An ExceptionID metadata indicates what 4231 caused the case. 4232 4233 4234 4235 IPv4Unicast 4236 4237 4238 ExceptionID 4239 4240 4241 4242 4243 4244 4245 IPv4NextHopTable 4246 4247 The IPv4NextHopTable component. A 4248 HopSelector is used to match the table index 4249 to find out a row which contains the next hop 4250 information result. 4251 4252 IPv4NextHopTableType 4253 4254 4255 4256 4257 IPv6NextHop 4258 4259 The LFB abstracts the process of next hop information 4260 application to IPv6 packets. It receives an IPv6 packet 4261 with an associated next hop identifier (HopSelector), 4262 uses the identifier as a table index to look up a next hop 4263 table to find an appropriate output port. 4264 4265 1.0 4266 4267 4268 PktsIn 4269 4270 A port for input of unicast IPv6 packets, along with 4271 a HopSelector metadata. 4272 4273 4274 4275 IPv6Unicast 4276 4277 4278 HopSelector 4279 4280 4281 4282 4283 4284 4285 SuccessOut 4286 4287 The group port for output of packets who successfully 4288 found next hop information. Some metadata are 4289 associated with every packet. 4290 4291 4292 4293 IPv6Unicast 4294 4295 4296 L3PortID 4297 NextHopIPv6Addr 4298 4299 MediaEncapInfoIndex 4300 4301 4302 4303 4304 ExceptionOut 4305 4306 The output port for packets with exceptional or 4307 failure case. An ExceptionID metadata indicates what 4308 caused the case. 4309 4310 4311 4312 IPv6Unicast 4313 4314 4315 ExceptionID 4316 4317 4318 4319 4320 4321 4322 IPv6NextHopTable 4323 4324 The IPv6NextHopTable component. A HopSelector is used 4325 to match the table index to find out a row which 4326 contains the next hop information result. 4327 4328 IPv6NextHopTableType 4329 4330 4331 4332 4333 RedirectIn 4334 4335 The RedirectIn LFB abstracts the process for the ForCES CE to 4336 inject data packets into the ForCES FE LFBs. 4337 4338 1.0 4339 4340 4341 PktsOut 4342 4343 The output port of RedirectIn LFB, which is defined as 4344 a group port type. From LFB topology point of view, 4345 the RedirectIn LFB acts as a source point for data 4346 packets coming from CE, therefore the LFB is 4347 defined with a singleton output port (and no input 4348 port). 4349 4350 4351 4352 Arbitrary 4353 4354 4355 4356 4357 4358 4359 NumPacketsReceived 4360 4361 Number of packets received from CE. 4362 4363 4364 uint64 4365 4366 4367 4368 4369 RedirectOut 4370 4371 The RedirectOut LFB abstracts the process for LFBs in a 4372 ForCES FE to deliver data packets to the ForCES CE. 4373 4374 1.0 4375 4376 4377 PktsIn 4378 4379 The input port for the RedirectOut LFB. From the LFB's 4380 topology point of view, the RedirectOut LFB acts as a 4381 sink point for data packets going to the CE, therefore 4382 RedirectOut LFB is defined with a singleton input 4383 port (and no output port). 4384 4385 4386 4387 Arbitrary 4388 4389 4390 4391 4392 4393 4394 NumPacketsSent 4395 4396 Numble of packets sent to CE. 4397 4398 4399 uint64 4400 4401 4402 4403 4404 BasicMetadataDispatch 4405 4406 The BasicMetadataDispatch LFB is defined to abstract the 4407 process by which packets are dispatched to various output 4408 paths based on associated metadata value. Current version of 4409 the LFB only allows the metadata value be 32-bits integer. 4410 4411 1.0 4412 4413 4414 PktsIn 4415 4416 The packet input port for dispatching. Every input 4417 packet should be associated with a metadata that will 4418 be used by the LFB to do the dispatch. 4419 4420 4421 4422 Arbitrary 4423 4424 4425 Arbitrary 4426 4427 4428 4429 4430 4431 4432 PktsOut 4433 4434 The group output port which outputs dispatching 4435 results. A packet with its associated metadata having 4436 found an OutputIndex by successfully looking up the 4437 dispatch table will be output to the group port 4438 instance with the corresponding index. 4439 4440 4441 4442 Arbitrary 4443 4444 4445 4446 4447 ExceptionOut 4448 4449 The output port which outputs packets which failed 4450 to process. An ExceptionID metadata indicates what 4451 caused the exception. 4452 4453 4454 4455 Arbitrary 4456 4457 4458 ExceptionID 4460 4461 4462 4463 4464 4465 4466 MetadataID 4467 4468 The ID of the metadata to be 4469 used for dispatching packets. 4470 4471 uint32 4472 4473 4474 MetadataDispatchTable 4475 4476 The MetadataDispatchTable component, which contains 4477 entries of a metadata value and an output index, 4478 specifying that a packet with the metadata value must 4479 go out from the instance with the output index of the 4480 LFB group output port. 4481 4482 MetadataDispatchTableType 4483 4484 4485 4486 4487 GenericScheduler 4488 4489 This is a preliminary generic scheduler LFB abstracting 4490 a simple scheduling process, which may be used as a 4491 basic LFB to construct a more complex scheduler LFB. 4492 4493 1.0 4494 4495 4496 PktsIn 4497 4498 The group input port of the LFB. Inside the LFB, 4499 each instance of the group port is connected to 4500 a queue marked with a queue ID, whose value is 4501 index of the port instance. 4502 4503 4504 4505 Arbitrary 4506 4507 4509 4510 4511 4512 4513 PktsOut 4514 4515 The output port of the LFB. Scheduled packets are 4516 output from the port. 4517 4518 4519 4520 Arbitrary 4521 4522 4523 4524 4525 4526 4527 SchedulingDiscipline 4528 4529 The SchedulingDiscipline component, which is for the 4530 CE to specify a scheduling discipline to the LFB. 4531 4532 SchdDisciplineType 4533 1 4534 4535 4536 QueueStats 4537 4538 The QueueStats component, which is defined to allow 4539 CE to query every queue statistics in the scheduler. 4540 4541 4542 QueueStatsTableType 4543 4544 4545 4546 4547 QueueLenLimit 4548 4549 The QueueLenLimit capability, which specifies 4550 maximum length of each queue. The length unit is in 4551 bytes. 4552 4553 uint32 4554 4555 4556 4558 4559 4560 7. LFB Class Use Cases 4562 This section demonstrates examples on how the LFB classes defined by 4563 the Base LFB library in Section 6 can be applied to achieve some 4564 typical router functions. The functions demonstrated are: 4566 o IPv4 forwarding 4568 o ARP processing 4570 It is assumed the LFB topology on the FE described has already been 4571 established by the CE and maps to the use cases illustrated in this 4572 section. 4574 The use cases demonstrated in this section are mere examples and by 4575 no means should be treated as the only way one would construct router 4576 functionality from LFBs; based on the capability of the FE(s), a CE 4577 should be able to express different NE applications. 4579 7.1. IPv4 Forwarding 4581 Figure 2 shows the typical LFB processing path for an IPv4 unicast 4582 forwarding case with Ethernet media interfaces by use of the base LFB 4583 classes. Note that in the figure, to focus on the IP forwarding 4584 function, some inputs or outputs of LFBs that are not related to the 4585 IPv4 forwarding function are not shown. For example, an 4586 EtherClassifier LFB normally has two output ports: a "ClassifyOut" 4587 group output port and a "ExceptionOut" singleton output port, with 4588 the group port contains various port instances according to various 4589 classified packet types(Section 5.1.3). While in this figure, only 4590 the IPv4 and IPv6 packet output port instances are shown for 4591 displaying the mere IPv4 forwarding processing function. 4593 +-----+ +------+ 4594 | | | | 4595 | |<---------------|Ether |<----------------------------+ 4596 | | |MACOut| | 4597 | | | | | 4598 |Ether| +------+ | 4599 |PHY | | 4600 |Cop | +---+ | 4601 |#1 | +-----+ | |----->IPv6 Packets | 4602 | | | | | | | 4603 | | |Ether| | | IPv4 Packets | 4604 | |->|MACIn|-->| |-+ +----+ | 4605 +-----+ | | | | | | |---> Multicast Packets | 4606 +-----+ +---+ | | | +-----+ +---+ | 4607 Ether +->| |------->| | | | | 4608 . Classifier| | |Unicast |IPv4 | | | | 4609 . | | |Packets |Ucast|->| |--+ | 4610 . | +----+ |LPM | | | | | 4611 +---+ | IPv4 +-----+ +---+ | | 4612 +-----+ | | | Validator IPv4 | | 4613 | | | | | NextHop| | 4614 +-----+ |Ether| | |-+ IPv4 Packets | | 4615 | |->|MACIn|-->| | | | 4616 | | | | | |----->IPv6 Packets | | 4617 |Ether| +-----+ +---+ | | 4618 |PHY | Ether +----+ | | 4619 |Cop | Classifier | | +-------+ | | 4620 |#n | +------+ | | |Ether | | | 4621 | | | | | |<--|Encap |<-+ | 4622 | | | |<------| | | | | 4623 | |<---------------|Ether | ...| | +-------+ | 4624 | | |MACOut| +---| | | 4625 | | | | | +----+ | 4626 +-----+ +------+ | BasicMetadataDispatch | 4627 +----------->-------------+ 4629 Figure 2: LFB use case for IPv4 forwarding 4631 In the LFB use case, a number of EtherPHYCop LFB(Section 5.1.1) 4632 instances are used to describe physical layer functions of the ports. 4633 PHYPortID metadata is generated by EtherPHYCop LFB and is used by all 4634 the subsequent downstream LFBs. An EtherMACIn LFB(Section 5.1.2), 4635 which describe the MAC layer processing, follows every EtherPHYCop 4636 LFB. The EtherMACIn LFB may do a locality check of MAC addresses if 4637 the CE configures the appropriate EtherMACIn LFB component. 4639 Ethernet packets out of the EtherMACIn LFB are sent to an 4640 EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified 4641 into network layer types like IPv4, IPv6, ARP, etc. In the example 4642 use case, every physical Ethernet interface is associated with one 4643 Classifier instance; although not illustrated, it is also feasible 4644 that all physical interfaces are associated with only one Ethernet 4645 Classifier instance. 4647 EtherClassifier uses the PHYPortID metadata, the Ethernet type of the 4648 input packet, and VlanID (if present in the input Ethernet packets), 4649 to decide the packet network layer type and the LFB output port to 4650 the downstream LFB. The EtherClassifier LFB also assigns a new 4651 logical port ID metadata to the packet for later use. The 4652 EtherClassifier may also generate some new metadata for every packet 4653 like EtherType, SrcMAC, DstMAC, LogicPortID, etc for consumption by 4654 downstream LFBs. 4656 If a packet is classified as an IPv4 packet, it is sent downstream to 4657 an IPv4Validator LFB (Section 5.2.1) to validate the IPv4 packet. In 4658 the validator LFB, IPv4 packets are validated and are additionally 4659 classified into either IPv4 unicast packets or multicast packets. 4660 IPv4 unicast packets are sent to downstream to the IPv4UcastLPM LFB 4661 (Section 5.3.1). 4663 The IPv4UcastLPM LFB is where the longest prefix match decision is 4664 made, and a next hop selection is selected. The next hop ID metadata 4665 is generated by the IPv4UcastLPM LFB to be consumed downstream by the 4666 IPv4NextHop LFB (Section 5.3.2). 4668 The IPv4NextHop LFB uses the next hop ID metadata to do derive where 4669 the packet is to go next and the media encapsulation type for the 4670 port, etc. The IPv4NextHop LFB generates the L3PortID metadata used 4671 to identify a next hop output physical/logical port. In the example 4672 use case, the next hop output port is an Ethernet type; as a result, 4673 the packet and its L3 port ID metadata are sent downstream to an 4674 EtherEncap LFB (Section 5.1.4). 4676 The EtherEncap LFB encapsulates the incoming packet into an Ethernet 4677 frame. A BasicMetadataDispatch LFB (Section 5.5.1) follows the 4678 EtherEncap LFB. The BasicMetadataDispatch LFB is where packets are 4679 finally dispatched to different output physical/logical ports based 4680 on the L3PortID metadata sent to the LFB. 4682 7.2. ARP processing 4684 Figure 3 shows the processing path for ARP protocol in the case the 4685 CE implements the ARP processing function. By no means is this the 4686 only way ARP processing could be achieved; as an example ARP 4687 processing could happen at the FE - but that discussion is out of 4688 scope for this use case. 4690 +---+ +---+ 4691 | | ARP packets | | 4692 | |-------------->---------+--->| | To CE 4693 ...-->| | . | | | 4694 | | . | +---+ 4695 | | . | RedirectOut 4696 +---+ ^ 4697 Ether EtherEncap | IPv4 packets lack 4698 Classifier +---+ | address resolution information 4699 | | | 4700 Packets need | |--------->---+ 4701 ...--------->| | 4702 L2 Encapsulation| | 4703 +---+ | | +------+ 4704 | | +-->| |--+ +---+ |Ether | 4705 | | | +---+ | | |--------->|MACOut|-->... 4706 From CE| |--+ +-->| | . +------+ 4707 | |ARP Packets | | . 4708 | |from CE | | . +------+ 4709 | | | |--------> |Ether |-->... 4710 +---+ +---+ |MACOut| 4711 RedirectIn BasicMetadata +------+ 4712 Dispatch 4714 Figure 3: LFB use case for ARP 4716 There are two ways ARP processing could be triggered in the CE as 4717 illustrated in Figure 3: 4719 o ARP packets arriving from outside of the NE. 4721 o IPV4 packets failing to resolve within the FE. 4723 ARP packets from network interfaces are filtered out by 4724 EtherClassifier LFB. The classified ARP packets and associated 4725 metadata are then sent downstream to the RedirectOut LFB 4726 (Section 5.4.2) to be transported to CE. 4728 The EtherEncap LFB, as described in Section 5.1.4, receives packets 4729 that need Ethernet L2 encapsulating. When the EtherEncap LFB fails 4730 to find the necessary L2 Ethernet information to encapsulate the 4731 packet with, it outputs the packet to its ExceptionOut LFB port. 4732 Downstream to EtherEncap LFB's ExceptionOut LFB port is the 4733 RedirectOut LFB which transports the packet to the CE (Section 5.1.4 4734 on EtherEncap LFB for details). 4736 To achieve its goal, the CE needs to generate ARP request and 4737 response packets and send them to external (to the NE) networks. ARP 4738 request and response packets from the CE are redirected to an FE via 4739 a RedirectIn LFB (Section 5.4.1). 4741 As was the case with forwarded IPv4 packets, outgoing ARP packets are 4742 also encapsulated to Ethernet format by the EtherEncap LFB, and then 4743 dispatched to different interfaces via a BasicMetadataDispatch LFB. 4744 The BasicMetadataDispatch LFB dispatches the packets according to the 4745 L3PortID metadata included in every ARP packet sent from CE. 4747 8. Contributors 4749 The authors would like to thank Jamal Hadi Salim, Ligang Dong, and 4750 Fenggen Jia who made major contributions to the development of this 4751 document. Ligang Dong and Fenggen Jia were also two of the authors 4752 of earlier documents which this document is evolved from. 4754 Jamal Hadi Salim 4755 Mojatatu Networks 4756 Ottawa, Ontario 4757 Canada 4758 Email: hadi@mojatatu.com 4760 Ligang Dong 4761 Zhejiang Gongshang University 4762 18 Xuezheng Str., Xiasha University Town 4763 Hangzhou,310018 4764 P.R.China 4765 EMail: donglg@zjsu.edu.cn 4767 Fenggen Jia 4768 National Digital Switching Center(NDSC) 4769 Jianxue Road 4770 Zhengzhou 452000 4771 P.R.China 4772 EMail: jfg@mail.ndsc.com.cn 4774 9. Acknowledgements 4776 The authors would like to acknowledge the following people, whose 4777 input has been particularly helpful during development of this 4778 document: 4780 Edward Crabbe 4781 Adrian Farrel 4782 Rong Jin 4783 Bin Zhuge 4784 Ming Gao 4785 Jingjing Zhou 4786 Xiaochun Wu 4787 Derek Atkins 4788 Stephen Farrel 4789 Meral Shirazipour 4790 Jari Arkko 4791 Martin Stiemerling 4792 Stewart Bryant 4793 Richard Barnes 4795 10. IANA Considerations 4797 IANA has created a registry of ForCES LFB Class Names and the 4798 corresponding ForCES LFB Class Identifiers, with the location of the 4799 definition of the ForCES LFB Class, in accordance with the rules to 4800 use the namespace. 4802 The LFB library in this document needs for unique class names and 4803 numeric class identifiers of all LFBs. Besides, this document also 4804 needs to define the following namespaces: 4806 o Metadata ID, defined in Section 4.3 and Section 4.4 4808 o Exception ID, defined in Section 4.4 4810 o Validate Error ID, defined in Section 4.4 4812 10.1. LFB Class Names and LFB Class Identifiers 4814 LFB classes defined by this document belongs to IETF defined LFBs by 4815 Standard Track RFCs. According to IANA, the identifier namespace for 4816 these LFB classes is from 3 to 65535. 4818 The assignment of LFB class names and LFB class identifiers is as in 4819 the following table. 4821 +-----------+---------------+------------------------+--------------+ 4822 | LFB Class | LFB Class Name| Description | Reference | 4823 | Identifier| | | | 4824 +-----------+---------------+------------------------+--------------+ 4825 | 3 | EtherPHYCop | Define an Ethernet port| RFC????(this| 4826 | | | abstracted at physical | document) | 4827 | | | layer. | Section 5.1.1| 4828 | | | | | 4829 | 4 | EtherMACIn | Define an Ethernet | RFC???? | 4830 | | | input port at MAC data | Section 5.1.2| 4831 | | | link layer. | | 4832 | | | | | 4833 | 5 |EtherClassifier| Define the process to | RFC???? | 4834 | | | decapsulate Ethernet | Section 5.1.3| 4835 | | | packets and classify | | 4836 | | | the packets. | | 4837 | | | | | 4838 | 6 | EtherEncap | Define the process to | RFC???? | 4839 | | | encapsulate IP packets | Section 5.1.4| 4840 | | | to Ethernet packets. | | 4841 | | | | | 4842 | 7 | EtherMACOut | Define an Ethernet | RFC ???? | 4843 | | | output port at MAC | Section 5.1.5| 4844 | | | data link layer. | | 4845 | | | | | 4846 | 8 | IPv4Validator | Perform IPv4 packets | RFC ???? | 4847 | | | validation. | Section 5.2.1| 4848 | | | | | 4849 | 9 | IPv6Validator | Perform IPv6 packets | RFC ???? | 4850 | | | validation. | Section 5.2.2| 4851 | | | | | 4852 | 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? | 4853 | | | Prefix Match Lookup. | Section 5.3.1| 4854 | | | | | 4855 | 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC ???? | 4856 | | | Prefix Match Lookup. | Section 5.3.3| 4857 | | | | | 4858 | 12 | IPv4NextHop | Define the process of | RFC ??? | 4859 | | | selecting Ipv4 next hop| Section 5.3.2| 4860 | | | action. | | 4861 | | | | | 4862 | 13 | IPv6NextHop | Define the process of | RFC ??? | 4863 | | | selecting Ipv6 next hop| Section 5.3.4| 4864 | | | action. | | 4865 | | | | | 4866 | 14 | RedirectIn | Define the process for | RFC ??? | 4867 | | | CE to inject data | Section 5.4.1| 4868 | | | packets into FE LFB | | 4869 | | | topology. | | 4870 | | | | | 4871 | 15 | RedirectOut | Define the process for | RFC ??? | 4872 | | | LFBs in FE to deliver | Section 5.4.2| 4873 | | | data packets to CE. | | 4874 | | | | | 4875 | 16 | BasicMetadata | Dispatch input packets | RFC ??? | 4876 | | Dispatch | to a group output | Section 5.5.1| 4877 | | | according to a metadata| | 4878 | | | | | 4879 | 17 | Generic | Define a preliminary | RFC ???? | 4880 | | Scheduler | generic scheduling | Section 5.5.2| 4881 | | | process. | | 4882 +-----------+---------------+------------------------+--------------+ 4884 Table 1 4886 10.2. Metadata ID 4888 The Metadata ID namespace is 32 bits long. The following is the 4889 guideline for managing the namespace. 4891 Metadata ID 0x00000000-0x7FFFFFFF 4892 Metadata with IDs in this range are Specification Required 4893 [RFC5226]. A metadata ID using this range MUST be documented in 4894 an RFC or other permanent and readily available references. 4896 Values assigned by this specification: 4898 +--------------+-------------------------+--------------------------+ 4899 | Value | Name | Definition | 4900 +--------------+-------------------------+--------------------------+ 4901 | 0x00000001 | PHYPortID | See Section 4.4 | 4902 | 0x00000002 | SrcMAC | See Section 4.4 | 4903 | 0x00000003 | DstMAC | See Section 4.4 | 4904 | 0x00000004 | LogicalPortID | See Section 4.4 | 4905 | 0x00000005 | EtherType | See Section 4.4 | 4906 | 0x00000006 | VlanID | See Section 4.4 | 4907 | 0x00000007 | VlanPriority | See Section 4.4 | 4908 | 0x00000008 | NextHopIPv4Addr | See Section 4.4 | 4909 | 0x00000009 | NextHopIPv6Addr | See Section 4.4 | 4910 | 0x0000000A | HopSelector | See Section 4.4 | 4911 | 0x0000000B | ExceptionID | See Section 4.4 | 4912 | 0x0000000C | ValidateErrorID | See Section 4.4 | 4913 | 0x0000000D | L3PortID | See Section 4.4 | 4914 | 0x0000000E | RedirectIndex | See Section 4.4 | 4915 | 0x0000000F | MediaEncapInfoIndex | See Section 4.4 | 4916 +--------------+-------------------------+--------------------------+ 4918 Table 2 4920 Metadata ID 0x80000000-0xFFFFFFFF 4921 Metadata IDs in this range are reserved for vendor private 4922 extensions and are the responsibility of individuals, i.e., used 4923 according to the Private Use [RFC5226] policy. 4925 10.3. Exception ID 4927 The Exception ID namespace is 32 bits long. The following is the 4928 guideline for managing the namespace. 4930 Exception ID 0x00000000-0x7FFFFFFF 4931 Exception IDs in this range are Specification Required [RFC5226]. 4932 An exception ID using this range MUST be documented in an RFC or 4933 other permanent and readily available references. 4935 Values assigned by this specification: 4937 +--------------+---------------------------------+------------------+ 4938 | Value | Name | Definition | 4939 +--------------+---------------------------------+------------------+ 4940 | 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 | 4941 | 0x00000001 | ClassifyNoMatching | See Section 4.4 | 4942 | 0x00000002 | MediaEncapInfoIndexInvalid | See Section 4.4 | 4943 | 0x00000003 | EncapTableLookupFailed | See Section 4.4 | 4944 | 0x00000004 | BadTTL | See Section 4.4 | 4945 | 0x00000005 | IPv4HeaderLengthMismatch | See Section 4.4 | 4946 | 0x00000006 | RouterAlertOptions | See Section 4.4 | 4947 | 0x00000007 | IPv6HopLimitZero | See Section 4.4 | 4948 | 0x00000008 | IPv6NextHeaderHBH | See Section 4.4 | 4949 | 0x00000009 | SrcAddressExecption | See Section 4.4 | 4950 | 0x0000000A | DstAddressExecption | See Section 4.4 | 4951 | 0x0000000B | LPMLookupFailed | See Section 4.4 | 4952 | 0x0000000C | HopSelectorInvalid | See Section 4.4 | 4953 | 0x0000000D | NextHopLookupFailed | See Section 4.4 | 4954 | 0x0000000E | FragRequired | See Section 4.4 | 4955 | 0x0000000F | MetadataNoMatching | See Section 4.4 | 4956 +--------------+---------------------------------+------------------+ 4958 Table 3 4960 Exception ID 0x80000000-0xFFFFFFFF 4961 Exception IDs in this range are reserved for vendor private 4962 extensions and are the responsibility of individuals, i.e., used 4963 according to the Private Use [RFC5226] policy. 4965 10.4. Validate Error ID 4967 The Validate Error ID namespace is 32 bits long. The following is 4968 the guideline for managing the namespace. 4970 Validate Error ID 0x00000000-0x7FFFFFFF 4971 Validate Error IDs in this range are Specification Required 4972 [RFC5226]. A Validate Error ID using this range MUST be 4973 documented in an RFC or other permanent and readily available 4974 references. 4976 Values assigned by this specification: 4978 +--------------+---------------------------------+------------------+ 4979 | Value | Name | Definition | 4980 +--------------+---------------------------------+------------------+ 4981 | 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 | 4982 | 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 | 4983 | 0x00000002 | NotIPv4Packet | See Section 4.4 | 4984 | 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 | 4985 | 0x00000004 | InvalidIPv4LengthFieldSize | See Section 4.4 | 4986 | 0x00000005 | InvalidIPv4Checksum | See Section 4.4 | 4987 | 0x00000006 | InvalidIPv4SrcAddr | See Section 4.4 | 4988 | 0x00000007 | InvalidIPv4DstAddr | See Section 4.4 | 4989 | 0x00000008 | InvalidIPv6PakcetSize | See Section 4.4 | 4990 | 0x00000009 | NotIPv6Packet | See Section 4.4 | 4991 | 0x0000000A | InvalidIPv6SrcAddr | See Section 4.4 | 4992 | 0x0000000B | InvalidIPv6DstAddr | See Section 4.4 | 4993 +--------------+---------------------------------+------------------+ 4994 Table 4 4996 Validate Error ID 0x80000000-0xFFFFFFFF 4997 Validate Error IDs in this range are reserved for vendor private 4998 extensions and are the responsibility of individuals, i.e., used 4999 according to the Private Use [RFC5226] policy. 5001 11. Security Considerations 5003 The ForCES framework document [RFC3746] provides a description of the 5004 security needs for the overall ForCES architecture. For example, the 5005 ForCES protocol entities must be authenticated per the ForCES 5006 requirements before they can access the information elements 5007 described in this document via ForCES. The ForCES protocol document 5008 [RFC5810] includes a comprehensive set of security mechanisms that 5009 implementations are required to support to meet these needs. The 5010 SCTP-based Transport Mapping Layer (TML) for the ForCES [RFC5811] 5011 specifies security mechanisms for transport mapping for ForCES 5012 protocol. The LFBs defined in this document are similar to other 5013 LFBs modeled by the FE model [RFC5812]. In particular, they have the 5014 same security properties. Thus the security mechanisms and 5015 considerations from the ForCES protocol document [RFC5810] apply and 5016 address the issues. 5018 12. References 5020 12.1. Normative References 5022 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 5023 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 5024 Control Element Separation (ForCES) Protocol 5025 Specification", RFC 5810, March 2010. 5027 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 5028 Layer (TML) for the Forwarding and Control Element 5029 Separation (ForCES) Protocol", RFC 5811, March 2010. 5031 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 5032 Element Separation (ForCES) Forwarding Element Model", 5033 RFC 5812, March 2010. 5035 12.2. Informative References 5037 [RFC1122] Braden, R., "Requirements for Internet Hosts - 5038 Communication Layers", STD 3, RFC 1122, October 1989. 5040 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 5041 RFC 1812, June 1995. 5043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5044 Requirement Levels", BCP 14, RFC 2119, March 1997. 5046 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5047 (IPv6) Specification", RFC 2460, December 1998. 5049 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 5050 Schoenwaelder, Ed., "Structure of Management Information 5051 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 5053 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 5054 June 1999. 5056 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 5057 Text on Security Considerations", BCP 72, RFC 3552, 5058 July 2003. 5060 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 5061 of IP Control and Forwarding", RFC 3654, November 2003. 5063 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 5064 "Forwarding and Control Element Separation (ForCES) 5065 Framework", RFC 3746, April 2004. 5067 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 5068 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 5069 May 2008. 5071 Authors' Addresses 5073 Weiming Wang 5074 Zhejiang Gongshang University 5075 18 Xuezheng Str., Xiasha University Town 5076 Hangzhou, 310018 5077 P.R.China 5079 Phone: +86 571 28877751 5080 Email: wmwang@zjsu.edu.cn 5082 Evangelos Haleplidis 5083 University of Patras 5084 Patras, 5085 Greece 5087 Email: ehalep@ece.upatras.gr 5089 Kentaro Ogawa 5090 NTT Corporation 5091 Tokyo, 5092 Japan 5094 Email: ogawa.kentaro@lab.ntt.co.jp 5096 Chuanhuang Li 5097 Hangzhou DPtech 5098 6th Floor, Zhongcai Group, 68 Tonghe Road, Binjiang District 5099 Hangzhou, 310051 5100 P.R.China 5102 Email: chuanhuang_li@zjsu.edu.cn 5104 Halpern Joel 5105 Ericsson 5106 P.O. Box 6049 5107 Leesburg, 20178 5108 VA 5110 Phone: +1 703 371 3043 5111 Email: joel.halpern@ericsson.com