idnits 2.17.1 draft-ietf-forces-lfb-lib-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5810], [RFC5812]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2011) is 4674 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: 'RFC1122' is mentioned on line 301, but not defined == Missing Reference: 'N' is mentioned on line 475, but not defined == Unused Reference: 'RFC1812' is defined on line 4240, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 4246, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 4249, but no explicit reference was found in the text -- 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: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 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: January 11, 2012 University of Patras 6 K. Ogawa 7 NTT Corporation 8 C. Li 9 Hangzhou BAUD Networks 10 J. Halpern 11 Ericsson 12 July 10, 2011 14 ForCES Logical Function Block (LFB) Library 15 draft-ietf-forces-lfb-lib-05 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 [RFC5812] 22 and ForCES protocol [RFC5810] specifications, and are scoped to meet 23 requirements of typical router functions and considered as the basic 24 LFB library for ForCES. The library includes the descriptions of the 25 LFBs and the 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 January 11, 2012. 44 Copyright Notice 46 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Scope of the Library . . . . . . . . . . . . . . . . . . . 7 66 3.2. Overview of LFB Classes in the Library . . . . . . . . . . 9 67 3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . . 9 68 3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 9 69 3.2.3. Sample LFB Class Application . . . . . . . . . . . . . 11 70 3.3. Document Structure . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . 38 80 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 38 81 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 38 82 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . . 40 83 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 42 84 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . . 44 85 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 46 86 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 47 87 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 47 88 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 49 89 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . . 51 90 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . . 51 91 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 53 92 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . . 55 93 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 57 94 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 58 95 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . . 59 96 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 59 97 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . . 60 98 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 60 99 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . . 61 100 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 64 101 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 86 102 7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 86 103 7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . . 87 104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 90 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 91 106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 107 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 92 108 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 94 109 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . . 94 110 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 95 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 97 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 98 113 12.1. Normative References . . . . . . . . . . . . . . . . . . . 98 114 12.2. Informative References . . . . . . . . . . . . . . . . . . 98 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99 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 128 Requirements in [RFC3654]and by the ForCES framework in [RFC3746]. 129 The 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 Topology - A representation of how the multiple FEs within a 157 single NE are interconnected. Sometimes this is called inter-FE 158 topology, to be distinguished from intra-FE topology (i.e., LFB 159 topology). 161 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. 162 An LFB Instance represents an LFB Class (or Type) existence. 163 There may be multiple instances of the same LFB Class (or Type) in 164 an FE. An LFB Class is represented by an LFB Class ID, and an LFB 165 Instance is represented by an LFB Instance ID. As a result, an 166 LFB Class ID associated with an LFB Instance ID uniquely specifies 167 an LFB existence. 169 LFB Metadata - Metadata is used to communicate per-packet state 170 from one LFB to another, but is not sent across the network. The 171 FE model defines how such metadata is identified, produced and 172 consumed by the LFBs. It defines the functionality but not how 173 metadata is encoded within an implementation. 175 LFB Component - Operational parameters of the LFBs that must be 176 visible to the CEs are conceptualized in the FE model as the LFB 177 components. The LFB components include, for example, flags, 178 single parameter arguments, complex arguments, and tables that the 179 CE can read and/or write via the ForCES protocol (see below). 181 LFB Topology - Representation of how the LFB instances are 182 logically interconnected and placed along the datapath within one 183 FE. Sometimes it is also called intra-FE topology, to be 184 distinguished from inter-FE topology. 186 ForCES Protocol - While there may be multiple protocols used 187 within the overall ForCES architecture, the term "ForCES protocol" 188 and "protocol" refer to the Fp reference points in the ForCES 189 Framework in [RFC3746]. This protocol does not apply to CE-to-CE 190 communication, FE-to-FE communication, or to communication between 191 FE and CE managers. Basically, the ForCES protocol works in a 192 master-slave mode in which FEs are slaves and CEs are masters. 193 This document defines the specifications for this ForCES protocol. 195 3. Introduction 197 RFC 3746 [RFC3746] specifies Forwarding and Control Element 198 Separation (ForCES) framework. In the framework, Control Elements 199 (CEs) configure and manage one or more separate Forwarding Elements 200 (FEs) within a Network Element (NE) by use of a ForCES protocol. RFC 201 5810 [RFC5810] specifies the ForCES protocol. RFC 5812 [RFC5812] 202 specifies the Forwarding Element (FE) model. In the model, resources 203 in FEs are described by classes of Logical Function Blocks (LFBs). 204 The FE model defines the structure and abstract semantics of LFBs, 205 and provides XML schema for the definitions of LFBs. 207 This document conforms to the specifications of the FE model 208 [RFC5812] and specifies detailed definitions of classes of LFBs, 209 including detailed XML definitions of LFBs. These LFBs form a base 210 LFB library for ForCES. LFBs in the base library are expected to be 211 combined to form an LFB topology for a typical router to implement IP 212 forwarding. It should be emphasized that an LFB is an abstraction of 213 functions rather than its implementation details. The purpose of the 214 LFB definitions is to represent functions so as to provide 215 interoperability between separate CEs and FEs. 217 More LFB classes with more functions may be developed in future time 218 and documented by IETF. Vendors may also develop proprietary LFB 219 classes as described in the FE model [RFC5812]. 221 3.1. Scope of the Library 223 It is intended that the LFB classes described in this document are 224 designed to provide the functions of a typical router. RFC 1812 225 specifies that a typical router is expected to provide functions to: 227 (1) Interface to packet networks and implement the functions required 228 by that network. These functions typically include: 230 o Encapsulating and decapsulating the IP datagrams with the 231 connected network framing (e.g., an Ethernet header and checksum), 233 o Sending and receiving IP datagrams up to the maximum size 234 supported by that network, this size is the network's Maximum 235 Transmission Unit or MTU, 237 o Translating the IP destination address into an appropriate 238 network-level address for the connected network (e.g., an Ethernet 239 hardware address), if needed, and 241 o Responding to network flow control and error indications, if any. 243 (2) Conform to specific Internet protocols including the Internet 244 Protocol (IPv4 and/or IPv6), Internet Control Message Protocol 245 (ICMP), and others as necessary. 247 (3) Receive and forwards Internet datagrams. Important issues in 248 this process are buffer management, congestion control, and fairness. 250 o Recognizes error conditions and generates ICMP error and 251 information messages as required. 253 o Drops datagrams whose time-to-live fields have reached zero. 255 o Fragments datagrams when necessary to fit into the MTU of the next 256 network. 258 (4) Choose a next-hop destination for each IP datagram, based on the 259 information in its routing database. 261 (5) Usually support an interior gateway protocol (IGP) to carry out 262 distributed routing and reachability algorithms with the other 263 routers in the same autonomous system. In addition, some routers 264 will need to support an exterior gateway protocol (EGP) to exchange 265 topological information with other autonomous systems. For all 266 routers, it is essential to provide ability to manage static routing 267 items. 269 (6) Provide network management and system support facilities, 270 including loading, debugging, status reporting, exception reporting 271 and control. 273 The classical IP router utilizing the ForCES framework constitutes a 274 CE running some controlling IGP and/or EGP function and FEs 275 implementing using Logical Function Blocks (LFBs) conforming to the 276 FE model[RFC5812] specifications. The CE, in conformance to the 277 ForCES protocol[RFC5810] and the FE model [RFC5812] specifications, 278 instructs the LFBs on the FE how to treat received/sent packets. 280 Packets in an IP router are received and transmitted on physical 281 media typically referred to as "ports". Different physical port 282 media will have different way for encapsulating outgoing frames and 283 decapsulating incoming frames. The different physical media will 284 also have different attributes that influence its behavior and how 285 frames get encapsulated or decapsulated. This document will only 286 deal with Ethernet physical media. Other future documents may deal 287 with other types of media. This document will also interchangeably 288 refer to a port to be an abstraction that constitutes a PHY and a MAC 289 as described by the LFBs like EtherPHYCop, EtherMACIn, and 290 EtherMACOut. 292 IP packets emanating from port LFBs are then processed by a 293 validation LFB before being further forwarded to the next LFB. After 294 the validation process the packet is passed to an LFB where IP 295 forwarding decision is made. In the IP Forwarding LFBs, a Longest 296 Prefix Match LFB is used to look up the destination information in a 297 packet and select a next hop index for sending the packet onward. A 298 next hop LFB uses the next hop index metadata to apply the proper 299 headers to the IP packets, and direct them to the proper egress. 300 Note that in the process of IP packets processing, in this document, 301 we are adhering to the weak-host model[RFC1122] since that is the 302 most usable model for a packet processing Network Element. 304 3.2. Overview of LFB Classes in the Library 306 It is critical to classify functional requirements into various 307 classes of LFBs and construct a typical but also flexible enough base 308 LFB library for various IP forwarding equipments. 310 3.2.1. LFB Design Choices 312 A few design principles were factored into choosing how the base LFBs 313 looked like. These are: 315 o if a function can be designed by either one LFB or two or more 316 LFBs with the same cost, the choice is to go with two or more LFBs 317 so as to provide more flexibility for implementers. 319 o when flexibility is not required, an LFB should take advantage of 320 its independence as much as possible and have minimal coupling 321 with other LFBs. The coupling may be from LFB attributes 322 definitions as well as physical implementations. 324 o unless there is a clear difference in functionality, similar 325 packet processing should not be represented as two or more 326 different LFBs. Or else, it may add extra burden on 327 implementation to achieve interoperability. 329 3.2.2. LFB Class Groupings 331 The document defines groups of LFBs for typical router function 332 requirements: 334 (1) A group of Ethernet processing LFBs are defined to abstract the 335 packet processing for Ethernet as the port media type. As the most 336 popular media type with rich processing features, Ethernet media 337 processing LFBs was a natural choice. Definitions for processing of 338 other port media types like POS or ATM may be incorporated in the 339 library in future version of the document or in a future separate 340 document. 342 The following LFBs are defined for Ethernet processing: 344 EtherPHYCop (section 5.1.1) 346 EtherMACIn (section 5.1.2) 348 EtherClassifier (section 5.1.3) 350 EtherEncapsulator (section 5.1.4) 352 EtherMACOut (section 5.1.5) 354 (2) A group of LFBs are defined for IP packet validation process. 356 The following LFBs are defined for IP Validation processing: 358 IPv4Validator (section 5.2.1) 360 IPv6Validator (section 5.2.2) 362 (3) A group of LFBs are defined to abstract IP forwarding process. 364 The following LFBs are defined for IP Forwarding processing: 366 IPv4UcastLPM (section 5.3.1) 368 IPv4NextHop (section 5.3.2) 370 IPv6UcastLPM (section 5.3.4) 372 IPv6NextHop (section 5.3.4) 374 (4) A group of LFBs are defined to abstract the process for redirect 375 operation, i.e., data packet transmission between CE and FEs. 377 The following LFBs are defined for redirect processing: 379 RedirectIn (section 5.4.1) 381 RedirectOut (section 5.4.2) 383 (5) A group of LFBs are defined for abstracting some general purpose 384 packet processing. These processing processes are usually general to 385 many processing locations in an FE LFB topology. 387 The following LFBs are defined for redirect processing: 389 BasicMetadataDispatch (section 5.5.1) 391 GenericScheduler (section 5.5.2) 393 3.2.3. Sample LFB Class Application 395 Although section 7 will present use cases for LFBs defined in this 396 document, this section shows a sample LFB class application in 397 advance so that readers can get a quick overlook of the LFB classes 398 with the usage. 400 Figure 1 shows the typical LFB processing path for an IPv4 unicast 401 forwarding case with Ethernet media interfaces. To focus on the IP 402 forwarding function, some inputs or outputs of LFBs in the figure 403 that are not related to the function are ignored. Section 7.1 will 404 describe the figure in more details. 406 +-----+ +------+ 407 | | | | 408 | |<---------------|Ether |<----------------------------+ 409 | | |MACOut| | 410 | | | | | 411 |Ether| +------+ | 412 |PHY | | 413 |Cop | +---+ | 414 |#1 | +-----+ | |----->IPv6 Packets | 415 | | | | | | | 416 | | |Ether| | | IPv4 Packets | 417 | |->|MACIn|-->| |-+ +----+ | 418 +-----+ | | | | | | |---> Multicast Packets | 419 +-----+ +---+ | | | +-----+ +---+ | 420 Ether +->| |------->| | | | | 421 . Classifier| | |Unicast |IPv4 | | | | 422 . | | |Packets |Ucast|->| |--+ | 423 . | +----+ |LPM | | | | | 424 +---+ | IPv4 +-----+ +---+ | | 425 +-----+ | | | Validator IPv4 | | 426 | | | | | NextHop| | 427 +-----+ |Ether| | |-+ IPv4 Packets | | 428 | |->|MACIn|-->| | | | 429 | | | | | |----->IPv6 Packets | | 430 |Ether| +-----+ +---+ | | 431 |PHY | Ether +----+ | | 432 |Cop | Classifier | | +-------+ | | 433 |#n | +------+ | | |Ether | | | 434 | | | | | |<--|Encap |<-+ | 435 | | | |<------| | | | | 436 | |<---------------|Ether | ...| | +-------+ | 437 | | |MACOut| +---| | | 438 | | | | | +----+ | 439 +-----+ +------+ | BasicMetadataDispatch | 440 +-------------------------+ 442 Figure 1: LFB use case for IPv4 forwarding 444 3.3. Document Structure 446 Base type definitions, including data types, packet frame types, and 447 etadata types are presented in advance for definitions of various LFB 448 classes. Section 4 (Base Types Section) provide a description on the 449 base types used by this LFB library. In order for an extensive use 450 of these base types for other LFB class definitions, the base type 451 definitions are provided by an xml file in a way as a library which 452 is separate from the LFB definition library. 454 Within every group of LFB classes, a set of LFBs are defined for 455 individual function purposes. Section 5 (LFB Class Descriptions 456 Section) makes text descriptions on the individual LFBs. Note that 457 for a complete definition of an LFB, a text description as well as a 458 XML definition is required. 460 LFB classes are finally defined by XML with specifications and schema 461 defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB 462 Definitions Section) provide the complete XML definitions of the base 463 LFB classes library.. 465 Section 7 provides several use cases on how some typical router 466 functions can be implemented using the base LFB library defined in 467 this document. 469 4. Base Types 471 TThe FE model [RFC5812] has specified predefined (built-in) atomic 472 data-types as below: 474 char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], 475 string, byte[N], boolean, octetstring[N], float16, float32, float64. 477 Based on the atomic data types and with the use of type definition 478 elements in the FE model XML schema, new data types, packet frame 479 types, and metadata types can be defined. 481 To define a base LFB library for typical router functions, a set of 482 base data types, frame types, and metadata types should be defined. 483 This section provides a brief description of the base types and a 484 full XML definition of them as well. 486 The base type XML definitions are provided with a separate XML 487 library file named "BaseTypeLibrary". Users can refer to this 488 library by the statement: 490 492 4.1. Data Types 494 Data types defined in the base type library are categorized by types 495 of atomic, compound struct, and compound array. 497 4.1.1. Atomic 499 The following data types are defined as atomic data types and put in 500 the base type library: 502 Data Type Name Brief Description 503 -------------- ----------------- 504 IPv4Addr IPv4 address 505 IPv6Addr IPv6 address 506 IEEEMAC IEEE mac address. 507 LANSpeedType Network speed values 508 DuplexType Duplex types 509 PortStatusValues The possible values of port status, used for 510 both administrative and operative status. 511 SchdDisciplineType Scheduling discipline type. 513 4.1.2. Compound struct 515 The following compound struct types are defined in the base type 516 library: 518 Data Type Name Brief Description 519 -------------- ----------------- 520 EtherDispatchEntryType Entry type for Ethernet dispatch table. 521 VlanInputTableEntryType Entry type for VLAN input table. 522 EncapTableEntryType Entry type for Ethernet encapsulation table. 523 MACInStatsType Statistics type for EtherMACIn LFB. 524 MACOutStatsType Statistics type for EtherMACOut LFB. 525 EtherClassifyStatsType Entry type for statistics table in 526 EtherClassifier LFB. 527 IPv4PrefixInfoType Entry type for IPv4 prefix table. 528 IPv6PrefixInfoType Entry type for IPv6 prefix table 529 IPv4NextHopInfoType Entry type for IPv4 next hop table. 530 IPv6NextHopInfoType Entry type for IPv6 next hop table. 531 IPv4ValidatorStatsType Statistics type in IPv4validator LFB. 532 IPv6ValidatorStatsType Statistics type in IPv6validator LFB. 533 IPv4UcastLPMStatsType Statistics type in IPv4Unicast LFB. 534 IPv6UcastLPMStatsType Statistics type in IPv6Unicast LFB. 535 QueueDepthType Entry type for queue depth table. 536 MetadataDispatchType Entry type for metadata dispatch table. 538 4.1.3. Compound array 540 Compound array types are mostly created based on compound struct 541 types for LFB table components. The following compound array types 542 are defined in this base type library: 544 Data Type Name Brief Description 545 -------------- ----------------- 546 EtherClassifyStatsTableType Type for Ethernet classifier statistics 547 information table 548 EtherDispatchTableType Type for Ethernet dispatch table. 549 VlanInputTableType Type for VLAN input table. 550 EncapTableType Type for Ethernet encapsulation table. 551 IPv4PrefixTableType Type for IPv4 prefix table. 552 IPv6PrefixTableType Type for IPv6 prefix table. 553 IPv4NextHopTableType Type for IPv4 next hop table. 554 IPv6NextHopTableType Type for IPv6 next hop table. 555 MetadataDispatchTableType Type for Metadata dispatch table. 556 QueueDepthTableType Type for Queue depth table. 558 4.2. Frame Types 560 According to FE model [RFC5812], frame types are used in LFB 561 definitions to define the types of frames the LFB expects at its 562 input port and emits at its output port. The element in 563 the FE model is used to define a new frame type. 565 The following frame types are defined in the base type library: 567 Frame Name Brief Description 568 -------------- ---------------- 569 EthernetII An Ethernet II frame 570 ARP An ARP packet 571 IPv4 An IPv4 packet 572 IPv6 An IPv6 packet 573 IPv4Unicast An IPv4 unicast packet 574 IPv4Multicast An IPv4 multicast packet 575 IPv6Unicast An IPv6 unicast packet 576 IPv6Multicast An IPv6 multicast packet 577 Arbitrary Any types of packet frames 579 4.3. MetaData Types 581 LFB Metadata is used to communicate per-packet state from one LFB to 582 another. The element in the FE model is used to define 583 a new metadata type. 585 The following metadata types are currently defined in the base type 586 library. 588 Metadata Name Metadata ID Brief Description 589 ------------ ---------- ------------- 590 PHYPortID 1 The physical port ID that the packet is 591 inputted. 592 SrcMAC 2 Source MAC address of the packet. 593 DstMAC 3 Destination MAC address of the packet. 594 LogicalPortID 4 ID of a logical port for the packet. 595 EtherType 5 Indicating the Ethernet type of the 596 Ethernet packet. 597 VlanID 6 The VLAN ID of the Ethernet packet. 598 VlanPriority 7 The priority of the Ethernet packet. 599 NexthopIPv4Addr 8 Nexthop IPv4 address the packet is sent to. 600 NexthopIPv6Addr 9 Nexthop IPv6 address the packet is sent to. 601 HopSelector 10 An index the packet can use to look up a 602 nexthop table for next hop information of 603 the packet. 604 ExceptionID 11 Indicating exception type of the packet 605 which is exceptional for some processing. 606 ValidateErrorID 12 Indicating error type of the packet failed 607 some validation process. 608 L3PortID 13 ID of L3 port. 609 RedirectIndex 14 A metadata CE sends to RedirectIn LFB for 610 the associated packet to select output 611 port in the LFB group output "PktsOut". 612 MediaEncapInfoIndex 15 An index the packet uses to look up a media 613 encapsulation table to select its 614 encapsulation media as well as followed 615 encapsulation LFB. 617 4.4. XML for Base Type Library 619 620 623 624 625 EthernetAll 626 All kinds of Ethernet frame 627 628 629 EthernetII 630 An Ethernet II frame 631 632 633 ARP 634 An arp packet 636 637 638 IPv4 639 An IPv4 packet 640 641 642 IPv6 643 An IPv6 packet 644 645 646 IPv4Unicast 647 An IPv4 unicast packet 648 649 650 IPv4Multicast 651 An IPv4 multicast packet 652 653 654 IPv6Unicast 655 An IPv6 unicast packet 656 657 658 IPv6Multicast 659 An IPv6 multicast packet 660 661 662 Arbitrary 663 Any types of packet frames 664 665 666 667 668 IPv4Addr 669 IPv4 address 670 byte[4] 671 672 673 IPv6Addr 674 IPv6 address 675 byte[16] 676 677 678 IEEEMAC 679 IEEE mac address. 680 byte[6] 681 682 683 LANSpeedType 684 Network speed values 685 686 uint32 687 688 689 LAN_SPEED_10M 690 10M Ethernet 691 692 693 LAN_SPEED_100M 694 100M Ethernet 695 696 697 LAN_SPEED_1G 698 1000M Ethernet 699 700 701 LAN_SPEED_10G 702 10G Ethernet 703 704 705 LAN_SPEED_AUTO 706 LAN speed auto 707 708 709 710 711 712 DuplexType 713 Duplex types 714 715 uint32 716 717 718 Auto 719 Auto negotitation. 720 721 722 Half-duplex 723 port negotitation half duplex 724 725 726 Full-duplex 727 port negotitation full duplex 728 729 730 731 733 734 735 PortStatusValues 736 The possible values of port status, used for both 737 administrative and operative status. 738 739 uchar 740 741 742 Disabled 743 the port is operatively disabled. 744 745 746 UP 747 the port is up. 748 749 750 Down 751 The port is down. 752 753 754 755 756 757 MACInStatsType 758 Statistics type in EtherMACIn. 759 760 761 NumPacketsReceived 762 The number of packets received. 763 uint64 764 765 766 NumPacketsDropped 767 The number of packets dropped. 768 uint64 769 770 771 772 773 MACOutStatsType 774 Statistics type in EtherMACOut. 775 776 777 NumPacketsTransmitted 778 The number of packets transmitted. 779 uint64 780 781 782 NumPacketsDropped 783 The number of packets dropped. 784 uint64 785 786 787 788 789 EtherDispatchEntryType 790 Entry type for Ethernet dispatch table. 791 792 793 LogicalPortID 794 Logical port ID. 795 uint32 796 797 798 EtherType 799 The EtherType value in the Ether head. 800 801 uint32 802 803 804 LFBOutputSelectIndex 805 LFB Group output port index to select 806 downstream LFB port. Some possibilities of downstream 807 LFB instances are: 808 a) IPv4Validator 809 b) IPv6Validator 810 c) RedirectOut 811 d) etc 812 Note: LFBOutputSelectIndex is the FromPortIndex for 813 the port group "ClassifyOut" in the table LFBTopology 814 (of FEObject LFB) as defined for the EtherClassifier 815 LFB. 816 uint32 817 818 819 820 821 EtherDispatchTableType 822 Type for Ethernet dispatch table. 823 824 EtherDispatchEntryType 825 826 827 828 VlanInputTableEntryType 829 Entry type for VLAN input table. 830 831 832 IncomingPortID 833 The incoming port ID. 834 uint32 835 836 837 VlanID 838 Vlan ID. 839 uint32 840 841 842 LogicalPortID 843 logical port ID. 844 uint32 845 846 847 848 849 VlanInputTableType 850 Type for VLAN input table. 851 852 VlanInputTableEntryType 853 854 855 856 EtherClassifyStatsType 857 Entry type for statistics table in EtherClassifier 858 LFB. 859 860 861 EtherType 862 The EtherType value 863 uint32 864 865 866 PacketsNum 867 Packets number 868 uint64 869 870 871 872 873 EtherClassifyStatsTableType 874 Type for Ethernet classifier statistics 875 information table. 876 877 EtherClassifyStatsType 878 879 880 881 IPv4ValidatorStatsType 882 Statistics type in IPv4validator. 883 884 885 badHeaderPkts 886 Number of bad header packets. 887 uint64 888 889 890 badTotalLengthPkts 891 Number of bad total length packets. 892 uint64 893 894 895 badTTLPkts 896 Number of bad TTL packets. 897 uint64 898 899 900 badChecksumPkts 901 Number of bad checksum packets. 902 uint64 903 904 905 906 907 IPv6ValidatorStatsType 908 Statistics type in IPv6validator. 909 910 911 badHeaderPkts 912 Number of bad header packets. 913 uint64 914 915 916 badTotalLengthPkts 917 Number of bad total length packets. 918 uint64 919 920 921 badHopLimitPkts 922 Number of bad Hop limit packets. 923 uint64 924 926 927 928 929 IPv4PrefixInfoType 930 Entry type for IPv4 prefix table. 931 932 933 IPv4Address 934 An IPv4 Address 935 IPv4Addr 936 937 938 Prefixlen 939 The prefix length 940 941 uchar 942 943 944 945 946 947 948 HopSelector 949 HopSelector is the nexthop ID which points to 950 the nexthop table 951 uint32 952 953 954 ECMPFlag 955 An ECMP Flag for this route 956 957 boolean 958 959 960 False 961 This route does not have multiple 962 nexthops. 963 964 965 True 966 This route has multiple nexthops. 967 968 969 970 971 972 973 DefaultRouteFlag 974 A default route flag. 975 976 boolean 977 978 979 False 980 This is not a default route. 981 982 983 984 True 985 This route is a default route. 986 987 988 989 990 991 992 993 994 IPv4PrefixTableType 995 Type for IPv4 prefix table. 996 997 IPv4PrefixInfoType 998 999 1000 1001 IPv4UcastLPMStatsType 1002 Statistics type in IPv4Unicast LFB. 1003 1004 1005 InRcvdPkts 1006 The total number of input packets received. 1007 1008 uint64 1009 1010 1011 FwdPkts 1012 IPv4 packets forwarded by this LFB 1013 uint64 1014 1015 1016 NoRoutePkts 1017 The number of IP datagrams discarded because 1018 no route could be found. 1019 uint64 1020 1021 1023 1024 1025 IPv6PrefixInfoType 1026 Entry type for IPv6 prefix table. 1027 1028 1029 IPv6Address 1030 An IPv6 Address 1031 IPv6Addr 1032 1033 1034 Prefixlen 1035 The prefix length 1036 1037 uchar 1038 1039 1040 1041 1042 1043 1044 HopSelector 1045 HopSelector is the nexthop ID which points 1046 to the nexthop table 1047 uint32 1048 1049 1050 ECMPFlag 1051 An ECMP Flag for this route 1052 1053 boolean 1054 1055 1056 False 1057 This route does not have multiple 1058 nexthops. 1059 1060 1061 True 1062 This route has multiple nexthops. 1063 1064 1065 1066 1067 1068 1069 DefaultRouteFlag 1070 A Default Route Flag. 1071 1072 boolean 1073 1074 1075 False 1076 This is not a default route. 1077 1078 1079 1080 True 1081 This route is a default route. 1082 1083 1084 1085 1086 1087 1088 1089 1090 IPv6PrefixTableType 1091 Type for IPv6 prefix table. 1092 1093 IPv6PrefixInfoType 1094 1095 1096 1097 IPv6UcastLPMStatsType 1098 Statistics type in IPv6Unicast LFB. 1099 1100 1101 InRcvdPkts 1102 The total number of input packets 1103 received 1104 uint64 1105 1106 1107 FwdPkts 1108 IPv6 packets forwarded by this LFB 1109 uint64 1110 1111 1112 NoRoutePkts 1113 The number of IP datagrams discarded because 1114 no route could be found. 1115 uint64 1116 1117 1118 1119 1120 IPv4NextHopInfoType 1121 Entry type for IPv4 next hop table. 1122 1123 1124 L3PortID 1125 The ID of the Logical/physical Output Port 1126 that we pass onto the neighboring LFB instance. This 1127 ID indicates what port to the neighbor is as defined 1128 by L3. 1129 uint32 1130 1131 1132 MTU 1133 Maximum Transmission Unit for out going port. 1134 It is for desciding whether the packet need 1135 fragmentation 1136 uint32 1137 1138 1139 NextHopIPAddr 1140 Next Hop IPv4 Address 1141 IPv4Addr 1142 1143 1144 MediaEncapInfoIndex 1145 The index we pass onto the neighboring LFB 1146 instance. This index is used to lookup a table 1147 (typically media encapsulatation related) further 1148 downstream. 1149 uint32 1150 1151 1152 LFBOutputSelectIndex 1153 LFB Group output port index to select 1154 downstream LFB port. Some possibilities of downstream 1155 LFB instances are: 1156 a) EtherEncap 1157 b) Other type of media LFB 1158 c) A metadata Dispatcher 1159 d) A redirect LFB 1160 e) etc 1161 Note: LFBOutputSelectIndex is the FromPortIndex for 1162 the port group "SuccessOut" in the table LFBTopology 1163 (of FEObject LFB) as defined for the IPv4NextHop LFB. 1164 1165 uint32 1166 1168 1169 1170 1171 IPv4NextHopTableType 1172 Type for IPv4 next hop table. 1173 1174 IPv4NextHopInfoType 1175 1176 1177 1178 IPv6NextHopInfoType 1179 Entry type for IPv6 next hop table. 1180 1181 1182 L3PortID 1183 The ID of the Logical/physical Output Port 1184 that we pass onto the neighboring LFB instance. This 1185 ID indicates what port to the neighbor is as defined 1186 by L3. 1187 uint32 1188 1189 1190 MTU 1191 Maximum Transmission Unit for out going port. 1192 It is for desciding whether the packet need 1193 fragmentation. 1194 uint32 1195 1196 1197 NextHopIPAddr 1198 Next Hop IPv6 Address 1199 IPv6Addr 1200 1201 1202 MediaEncapInfoIndex 1203 The index we pass onto the neighboring LFB 1204 instance. This index is used to lookup a table 1205 (typically media encapsulatation related) further 1206 downstream. 1207 uint32 1208 1209 1210 LFBOutputSelectIndex 1211 LFB Group output port index to select 1212 downstream LFB port. Some possibilities of downstream 1213 LFB instances are: 1214 a) EtherEncap 1215 b) Other type of media LFB 1216 c) A metadata Dispatcher 1217 d) A redirect LFB 1218 e) etc 1219 Note: LFBOutputSelectIndex is the FromPortIndex for 1220 the port group "SuccessOut" in the table LFBTopology 1221 (of FEObject LFB) as defined for the IPv6NextHop LFB. 1222 1223 uint32 1224 1225 1226 1227 1228 IPv6NextHopTableType 1229 Type for IPv6 next hop table. 1230 1231 IPv6NextHopInfoType 1232 1233 1234 1235 EncapTableEntryType 1236 Entry type for Ethernet encapsulation table. 1237 1238 1239 1240 DstMac 1241 Ethernet Mac of the Neighbor 1242 IEEEMAC 1243 1244 1245 SrcMac 1246 Source MAC used in encapsulation 1247 IEEEMAC 1248 1249 1250 VlanID 1251 VLAN ID. 1252 uint32 1253 1254 1255 L2PortID 1256 Output logical L2 port ID. 1257 uint32 1258 1259 1260 1261 1262 EncapTableType 1263 Type for Ethernet encapsulation table. 1264 1265 EncapTableEntryType 1266 1267 1268 1269 MetadataDispatchType 1270 Entry type for metadata dispatch table. 1271 1272 1273 MetadataID 1274 metadata ID 1275 uint32 1276 1277 1278 MetadataValue 1279 metadata value. 1280 uint32 1281 1282 1283 OutputIndex 1284 group output port index. 1285 uint32 1286 1287 1288 1289 1290 MetadataDispatchTableType 1291 Type for Metadata dispatch table. 1292 1293 MetadataDispatchType 1294 1295 1296 1297 SchdDisciplineType 1298 Scheduling discipline type. 1299 1300 uint32 1301 1302 1303 FIFO 1304 First In First Out scheduler. 1305 1306 1307 RR 1308 Round Robin. 1309 1310 1311 1313 1314 1315 QueueDepthType 1316 Entry type for queue depth table. 1317 1318 1319 QueueID 1320 Queue ID 1321 uint32 1322 1323 1324 QueueDepthInPackets 1325 the Queue Depth when the depth units 1326 are packets. 1327 uint32 1328 1329 1330 QueueDepthInBytes 1331 the Queue Depth when the depth units 1332 are bytes. 1333 uint32 1334 1335 1336 1337 1338 QueueDepthTableType 1339 Type for Queue depth table. 1340 1341 QueueDepthType 1342 1343 1344 1345 1346 1347 PHYPortID 1348 The physical port ID that a packet has entered. 1349 1350 1 1351 uint32 1352 1353 1354 SrcMAC 1355 Source MAC address of the packet. 1356 2 1357 IEEEMAC 1358 1359 1360 DstMAC 1361 Destination MAC address of the packet. 1362 3 1363 IEEEMAC 1364 1365 1366 LogicalPortID 1367 ID of a logical port for the packet. 1368 4 1369 uint32 1370 1371 1372 EtherType 1373 Indicating the Ethernet type of the Ethernet packet. 1374 1375 5 1376 uint32 1377 1378 1379 VlanID 1380 The Vlan ID of the Ethernet packet. 1381 6 1382 uint32 1383 1384 1385 VlanPriority 1386 The priority of the Ethernet packet. 1387 7 1388 uint32 1389 1390 1391 NexthopIPv4Addr 1392 Nexthop IPv4 address the packet is sent to. 1393 1394 8 1395 IPv4Addr 1396 1397 1398 NexthopIPv6Addr 1399 Nexthop IPv6 address the packet is sent to. 1400 1401 9 1402 IPv6Addr 1403 1404 1405 HopSelector 1406 An index the packet can use to look up a nexthop 1407 table for next hop information of the packet. 1408 10 1409 uint32 1410 1411 1412 ExceptionID 1413 Indicating exception type of the packet which is 1414 exceptional for some processing. 1415 11 1416 1417 uint32 1418 1419 1420 AnyUnrecognizedExceptionCase 1421 any unrecognized exception case. 1422 1423 1424 BroadCastPacket 1425 Packet with destination address equal to 1426 255.255.255.255 1427 1428 1429 BadTTL 1430 The packet can't be forwarded as the TTL 1431 has expired. 1432 1433 1434 IPv4HeaderLengthMismatch 1435 IPv4 Packet's header length is less 1436 than 5. 1437 1438 1439 LengthMismatch 1440 The packet length reported by link layer 1441 is less than the total length field. 1442 1443 1444 RouterAlertOptions 1445 Packet IP head include Router Alert 1446 options. 1447 1448 1449 RouteInTableNotFound 1450 There is no route in the route table 1451 corresponding to the packet destination address 1452 1453 1454 1455 NextHopInvalid 1456 The NexthopID is invalid 1458 1459 1460 FragRequired 1461 The MTU for outgoing interface is less 1462 than the packet size. 1463 1464 1465 LocalDelivery 1466 The packet is for a local interface. 1467 1468 1469 1470 GenerateICMP 1471 ICMP packet needs to be generated. 1472 1473 1474 1475 PrefixIndexInvalid 1476 The prefixIndex is wrong. 1477 1478 1479 IPv6HopLimitZero 1480 Packet with Hop Limit zero 1481 1482 1483 IPv6NextHeaderHBH 1484 Packet with next header set to Hop-by-Hop 1485 1486 1487 1488 1489 1490 1491 ValidateErrorID 1492 Indicating error type of the packet failed some 1493 validation process. 1494 12 1495 1496 uint32 1497 1498 1499 AnyUnrecognizedValidateErrorCase 1500 Any unrecognized validate error case. 1501 1502 1503 1504 InvalidIPv4PacketSize 1505 Packet size reported is less than 20 1506 bytes. 1507 1508 1509 NotIPv4Packet 1510 Packet is not IP version 4. 1511 1512 1513 InvalidIPv4HeaderLengthSize 1514 Packet's header length is less than 5. 1515 1516 1517 1518 InvalidIPv4Checksum 1519 Packet with invalid checksum. 1520 1521 1522 InvalidIPv4SrcAddrCase1 1523 Packet with source address equal to 1524 255.255.255.255. 1525 1526 1527 InvalidIPv4SrcAddrCase2 1528 Packet with source address 0. 1529 1530 1531 InvalidIPv4SrcAddrCase3 1532 Packet with source address of form 1533 127.any. 1534 1535 1536 InvalidIPv4SrcAddrCase4 1537 Packet with source address in Class E 1538 domain. 1539 1540 1541 InvalidIPv6PakcetSize 1542 Packet size reported is less than 40 1543 bytes. 1544 1545 1546 NotIPv6Packet 1547 Packet is not IP version 6. 1548 1549 1550 InvalidIPv6SrcAddrCase1 1551 Packet with multicast source address (the 1552 MSB of the source address is 0xFF). 1553 1554 1555 InvalidIPv6SrcAddrCase2 1556 Packet with source address set to 1557 loopback(::1). 1558 1559 1560 InvalidIPv6DstAddrCase1 1561 Packet with destination set to 0 or ::1. 1562 1563 1564 1565 1566 1567 1568 L3PortID 1569 ID of L3 port. 1570 13 1571 uint32 1572 1573 1574 RedirectIndex 1575 metadata CE sends to RedirectIn LFB for the 1576 associated packet to select output port in the LFB group 1577 output "PktsOut". 1578 14 1579 uint32 1580 1581 1582 MediaEncapInfoIndex 1583 An index the packet uses to look up a media 1584 encapsulation table to select its encapsulation media as 1585 well as followed encapsulation LFB. 1586 15 1587 uint32 1588 1589 1590 1592 5. LFB Class Description 1594 According to ForCES specifications, LFB (Logical Function Block) is a 1595 well defined, logically separable functional block that resides in an 1596 FE, and is a functionally accurate abstraction of the FE's processing 1597 capabilities. An LFB Class (or type) is a template that represents a 1598 fine-grained, logically separable aspect of FE processing. Most LFBs 1599 are related to packet processing in the data path. LFB classes are 1600 the basic building blocks of the FE model. Note that RFC 5810 has 1601 already defined an 'FE Protocol LFB' which is as a logical entity in 1602 each FE to control the ForCES protocol. RFC 5812 has already defined 1603 an 'FE Object LFB'. Information like the FE Name, FE ID, FE State, 1604 LFB Topology in the FE are represented in this LFB. 1606 As specified in Section 3.1, this document focuses the base LFB 1607 library for implementing typical router functions, especially for IP 1608 forwarding functions. As a result, LFB classes in the library are 1609 all base LFBs to implement router forwarding. 1611 5.1. Ethernet Processing LFBs 1613 As the most popular physical and data link layer protocols, Ethernets 1614 are widely deployed. It becomes a basic requirement for a router to 1615 be able to process various Ethernet data packets. 1617 Note that there exist different versions of Ethernet protocols, like 1618 Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP. 1619 There also exist varieties of LAN techniques based on Ethernet, like 1620 various VLANs, MACinMAC, etc. Ethernet processing LFBs defined here 1621 are intended to be able to cope with all these variations of Ethernet 1622 technology. 1624 There are also various types of Ethernet physical interface media. 1625 Among them, copper and fiber media may be the most popular ones. As 1626 a base LFB definition and a start work, the document only defines an 1627 Ethernet physical LFB with copper media. For other media interfaces, 1628 specific LFBs may be defined in the future versions of the library. 1630 5.1.1. EtherPHYCop 1632 EtherPHYCop LFB abstracts an Ethernet interface physical layer with 1633 media limited to copper. 1635 5.1.1.1. Data Handling 1637 This LFB is the interface to the Ethernet physical media. The LFB 1638 handles ethernet frames coming in from or going out of the FE. 1639 Ethernet frames sent and received cover all packets encapsulated with 1640 different versions of Ethernet protocols, like Ethernet V2, 802.3 1641 RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets 1642 encapsulated with varieties of LAN techniques based on Ethernet, like 1643 various VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll 1644 frame type has been introduced. 1646 Ethernet frames are received from the physical media port and passed 1647 downstream to LFBs such as EtherMACIn via a singleton output known as 1648 "EtherPHYOut". A 'PHYPortID' metadatum, to indicate which physical 1649 port the frame came into from the external world, is passed along 1650 with the frame. 1652 Ethernet packets are received by this LFB from upstream LFBs such 1653 EtherMacOut via the singleton input known as "EtherPHYIn" before 1654 being sent out onto the external world. 1656 5.1.1.2. Components 1658 The AdminStatus component is defined for CE to administratively 1659 manage the status of the LFB. The CE may adminstratively startup or 1660 shutdown the LFB by changing the value of AdminStatus. The default 1661 value is set to 'Down'. 1663 An OperStatus component captures the physical port operational 1664 status. A PHYPortStatusChanged event is defined so the LFB can 1665 report to the CE whenever there is an operational status change of 1666 the physical port. 1668 The PHYPortID component is a unique identification for a physical 1669 port. It is defined as 'read-only' by CE. Its value is enumerated 1670 by FE. The component will be used to produce a 'PHYPortID' metadatum 1671 at the LFB output and to associate it to every Ethernet packet this 1672 LFB receives. The metadatum will be handed to downstream LFBs for 1673 them to use the PHYPortID. 1675 A group of components are defined for link speed management. The 1676 AdminLinkSpeed is for CE to configure link speed for the port and the 1677 OperLinkSpeed is for CE to query the actual link speed in operation. 1678 The default value for the AdminLinkSpeed is set to auto-negotiation 1679 mode. 1681 A group of components are defined for duplex mode management. The 1682 AdminDuplexMode is for CE to configure proper duplex mode for the 1683 port and the OperDuplexMode is for CE to query the actual duplex mode 1684 in operation. The default value for the AdminDuplexMode is set to 1685 auto-negotiation mode. 1687 A CarrierStatus component captures the status of the carrier and 1688 specifies whether the port is linked with an operational connector. 1689 The default value for the CarrierStatus is 'false'. 1691 5.1.1.3. Capabilities 1693 The capability information for this LFB includes the link speeds that 1694 are supported by the FE (SupportedLinkSpeed) as well as the supported 1695 duplex modes (SupportedDuplexMode). 1697 5.1.1.4. Events 1699 This LFB is defined to be able to generate several events in which 1700 the CE may be interested. There is an event for changes in the 1701 status of the physical port (PhyPortStatusChanged). Such an event 1702 will notify that the physical port status has been changed and the 1703 report will include the new status of the physical port. 1705 Another event captures changes in the operational link speed 1706 (LinkSpeedChanged). Such an event will notify the CE that the 1707 operational speed has been changed and the report will include the 1708 new negotiated operational speed. 1710 A final event captures changes in the duplex mode 1711 (DuplexModeChanged). Such an event will notify the CE that the 1712 duplex mode has been changed and the report will include the new 1713 negotiated duplex mode. 1715 5.1.2. EtherMACIn 1717 EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. It 1718 specifically describes Ethernet processing functions like MAC address 1719 locality check, deciding if the Ethernet packets should be bridged, 1720 provide Ethernet layer flow control, etc. 1722 5.1.2.1. Data Handling 1724 The LFB is expected to receive all types of Ethernet packets, via a 1725 singleton input known as "EtherMACIn", which are usually output from 1726 some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside 1727 with a metadatum indicating the physical port ID that the packet 1728 comes. 1730 The LFB is defined with two separate singleton outputs. All Output 1731 packets are in Ethernet format, as received from the physical layer 1732 LFB and cover all types of Ethernet packets. 1734 The first singleton output is known as "NormalPathOut". It usually 1735 outputs Ethernet packets to some LFB like an EtherClassifier LFB for 1736 further L3 forwarding process alongside with a PHYPortID metadata 1737 indicating which physical port the packet came from. 1739 The second singleton output is known as "L2BridgingPathOut". 1740 Although the LFB library this document defines is basically to meet 1741 typical router functions, it will attempt to be forward compatible 1742 with future router functions. The "L2BridgingPathOut" is defined to 1743 meet the requirement that L2 bridging functions may be optionally 1744 supported simultaneously with L3 processing and some L2 bridging LFBs 1745 that may be defined in the future. If the FE supports L2 bridging, 1746 the CE can enable or disable it by means of a "L2BridgingPathEnable" 1747 component in the FE. If it is enabled, by also instantiating some L2 1748 bridging LFB instances following the L2BridgingPathOut, FEs are 1749 expected to fulfill L2 bridging functions. L2BridgingPathOut will 1750 output packets exactly the same as that in the NormalPathOut output. 1752 This LFB can be set to work in a Promiscuous Mode, allowing all 1753 packets to pass through the LFB without being dropped. Otherwise, a 1754 locality check will be performed based on the local MAC addresses. 1755 All packets that do not pass through the locality check will be 1756 dropped. 1758 This LFB can perform Ethernet layer flow control. This is usually 1759 implemented cooperatively by the EtherMACIn LFB and the EtherMACOut 1760 LFB. The flow control is further distinguished by Tx flow control 1761 and Rx flow control, separately for sending process and receiving 1762 process flow controls. 1764 5.1.2.2. Components 1766 The AdminStatus component is defined for CE to administratively 1767 manage the status of the LFB. The CE may administratively startup or 1768 shutdown the LFB by changing the value of AdminStatus. The default 1769 value is set to 'Down'. 1771 The LocalMACAddresses component specifies the local MAC addresses 1772 based on which locality checks will be made. This component is an 1773 array of MAC addresses, and of 'read-write' access permission. 1775 An L2BridgingPathEnable component captures whether the LFB is set to 1776 work as a L2 bridge. An FE that does not support bridging will 1777 internally set this flag to false, and additionally set the flag 1778 property as read-only. The default value for is 'false'. 1780 The PromiscuousMode component specifies whether the LFB is set to 1781 work as in a promiscuous mode. The default value for is 'false'. 1783 The TxFlowControl component defines whether the LFB is performing 1784 flow control on sending packets. The default value for is 'false' 1786 The RxFlowControl component defines whether the LFB is performing 1787 flow contron on receiving packets. The default value for is 'false'. 1789 A struct component, MACInStats, defines a set of statistics for this 1790 LFB, including the number of received packets and the number of 1791 dropped packets. 1793 5.1.2.3. Capabilities 1795 This LFB does not have a list of capabilities. 1797 5.1.2.4. Events 1799 This LFB does not have any events specified. 1801 5.1.3. EtherClassifier 1803 EtherClassifier LFB abstracts the process to decapsulate Ethernet 1804 packets and classify them. 1806 5.1.3.1. Data Handling 1808 This LFB describes the process of decapsulating Ethernet packets and 1809 classify them into various network layer data packets according to 1810 information included in the Ethernet packets headers. 1812 TThe LFB is expected to receive all types of Ethernet packets, 1813 including VLAN Ethernet types, via a singleton input known as 1814 "EtherPktsIn", which are usually output from an upstream LFB like 1815 EtherMACIn LFB. This input is also capable of multiplexing to allow 1816 for multiple upstream LFBs being connected. For instance, when L2 1817 bridging function is enabled in EtherMACIn LFB, some L2 bridging LFBs 1818 may be applied. In this case, some Ethernet packets after L2 1819 processing may have to be input to EtherClassifier LFB for 1820 classification, while simultaneously packets directly output from 1821 EtherMACIn may also need to input to this LFB. This input is capable 1822 of handling this case. Usually, all expected Ethernet Packets will 1823 be associated with a PHYPortID metadatum, indicating the physical 1824 port the packet comes from. In some cases, for instance, like in a 1825 MACinMAC case, a LogicalPortID metadatum may be expected to associate 1826 with the Ethernet packet to further indicate which logical port the 1827 Ethernet packet belongs to. Note that PHYPortID metadata is always 1828 expected while LogicalPortID metadata is optionally expected. 1830 The LFB is defined with a group output known as "ClassifyOut". 1831 Because there may be various types of protocol packets at the output 1832 ports, the produced output frame is defined as arbitrary for the 1833 purpose of wide extensibility in the future. In order for downstream 1834 LFBs to use, a bunch of metadata is produced to associate with every 1835 output packet. The medatdata, which may be used by downstream LFBs 1836 for packet processing, contains the PHYPortID and it also contains 1837 information on Ethernet type, source MAC address, and destination MAC 1838 address of its original Ethernet packet. Moreover, it contains 1839 information of logical port ID assigned by this LFB. Lastly, it may 1840 conditionally contain information like VlanID and VlanPriority with 1841 the condition that the packet is a VLAN packet. 1843 5.1.3.2. Components 1845 An EtherDispatchTable array component is defined in the LFB to 1846 dispatch every Ethernet packet to the output group according to the 1847 logical port ID assigned by the VLANInputTable to the packet and the 1848 Ethernet type in the Ethernet packet header. Each row of the array 1849 is a struct containing a Logical Port ID, an EtherType and an Output 1850 Index. With the CE configuring the dispatch table, the LFB can be 1851 expected to classify various network layer protocol type packets and 1852 output them at different output ports. It is expected that the LFB 1853 classify packets according to protocols like IPv4, IPv6, MPLS, ARP, 1854 ND, etc. 1856 A VLANInputTable array component is defined in the LFB to classify 1857 VLAN Ethernet packets. Each row of the array is a strcut containing 1858 an Incoming Port ID, a VLAN ID and a Logical Port ID. According to 1859 IEEE VLAN specifications, all Ethernet packets can be recognized as 1860 VLAN types by defining that if there is no VLAN encapsulation in a 1861 packet, a case with VLAN tag 0 is considered. Therefore the table 1862 actually applies to every input packet of the LFB. Every input 1863 packet is assigned with a new LogicalPortID according to the packet 1864 incoming port ID and the VLAN ID. A packet incoming port ID is 1865 defined as a physical port ID if there is no logical port ID 1866 associated with the packet, or a logical port ID if there is a 1867 logical port ID associated with the packet. The VLAN ID is exactly 1868 the Vlan ID in the packet if it is a VLAN packet, or 0 if it is not a 1869 VLAN packet. Note that a logical port ID of a packet may be 1870 rewritten with a new one by the VLANInputTable processing. 1872 Note that the logical port ID and physical port ID mentioned above 1873 are all originally configured by CE, and are globally effective 1874 within an ForCES NE (Network Element). To distinguish a physical 1875 port ID from a logical port ID in the incoming port ID field of the 1876 VLANInputTable, physical port ID and logical port ID must be assigned 1877 with separate number spaces. 1879 An array component, EtherClassifyStats, defines a set of statistics 1880 for this LFB, measuring the number of packets per EtherType. Each 1881 row of the array is a struct containing an EtherType and a Packet 1882 number. 1884 5.1.3.3. Capabilities 1886 This LFB does not have a list of capabilities. 1888 5.1.3.4. Events 1890 This LFB has no events specified. 1892 5.1.4. EtherEncap 1894 The EtherEncap LFB abstracts the process to replace or attach 1895 appropriate Ethernet headers to the packet. 1897 5.1.4.1. Data Handling 1899 This LFB abstracts the process to encapsulate IP packets to Ethernet 1900 packets according to the L2 information. 1902 The LFB is expected to receive types of IP packets, including IPv4 1903 and IPv6 types, via a singleton one known as "EncapIn" which may be 1904 connected to an upstream LFB like an IPv4NextHop, an IPv6NextHop, 1905 BasicMetadataDispatch, or any LFB which requires to output packets 1906 for Ethernet encapsulation. The LFB always expects from upstream 1907 LFBs the MediaEncapInfoIndex metadata which is used as an index to 1908 lookup the Encapsulation Table. Optinally an input packet may be 1909 accompanied by a Vlan priority metadata. In this case, default value 1910 for the metadata is 0. 1912 Two singleton output ports are defined to output results. 1914 The first singleton output known as "SuccessOut". Upon a successful 1915 table lookup, the destination and source MAC addresses, and the 1916 logical media port (L2PortID) are found in the matching table entry. 1917 The CE may set the VlanId in case VLANs are used. By default the 1918 table entry for VlanId of 0 is used as per IEEE rules. Whatever the 1919 value of VlanID is, if the Input metadata VlanPriority is non-zero, 1920 the packet will have a VLAN tag. If the VlanPriority and the VlanID 1921 are all zero, there is no VLAN tag to this packet. After replacing 1922 or attaching the appropriate Ethernet headers to the packet is 1923 complete, the packet is passed out on the "SuccessOut" LFB port to a 1924 downstream LFB instance alongside with the L2PortID. 1926 The second singleton output known as "ExceptionOut", which will 1927 output packets for which the table lookup fails, along with an 1928 additional ExceptionID metadata. Currently defined exception types 1929 only include the following case: 1931 o MediaEncapInfoIndex value is not allocated in the EncapTable. 1933 The upstream LFB may be programmed by the CE to pass along a 1934 MediaEncapInfoIndex that does not exist in the EncapTable. That is 1935 to allow for resolution of the L2 headers, if needed, to be made at 1936 the L2 encapsulation level in this case(ethernet) via ARP, or ND (or 1937 other methods depending on the link layer technology) when a table 1938 miss occurs. 1940 For neighbor L2 header resolution(table miss exception), the 1941 processing LFB may pass this packet to the CE via the redirect LFB or 1942 FE software or another LFB instance for further resolution. In such 1943 a case the metadata NexthopIPv4Addr or NexthopIPv6Addr generated by 1944 Nexthop LFB is also passed to the exception handling. Such an IP 1945 address could be used to do activities such as ARP or ND by the 1946 handler it is passed to. 1948 The result of the L2 resolution is to update the EncapTable as well 1949 as the Nexthop LFB so subsequent packets do not fail EncapTable 1950 lookup. The EtherEncap LFB does not make any assumptions of how the 1951 EncapTable is updated by the CE (or whether ARP/ND is used 1952 dynamically or static maps exist). 1954 Downstream neighboring LFB instances could be either an EtherMACOut 1955 type or a BasicMetadataDispatch type. If the final packet L2 1956 processing is possible to be on per-media-port basis or resides on a 1957 different FE or in cases where L2 header resolution is needed, then 1958 the model makes sense to use a BasicMetadataDispatch LFB to fanout to 1959 different LFB instances. If there is a direct egress port point, 1960 then the model makes sense to have a downstream LFB instance be an 1961 EtherMACOut. 1963 5.1.4.2. Components 1965 This LFB has only one component named EncapTable which is defined as 1966 an array. Each row of the array is a struct containing the 1967 destination MAC address, the source MAC address, the VLAN ID with a 1968 default value of zero and the output logical L2 port ID. 1970 5.1.4.3. Capabilities 1972 This LFB does not have a list of capabilities. 1974 5.1.4.4. Events 1976 This LFB does not have any events specified. 1978 5.1.5. EtherMACOut 1980 EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. 1981 This LFB describes Ethernet packet output process. Ethernet output 1982 functions are closely related to Ethernet input functions, therefore 1983 many components defined in this LFB are as aliases of EtherMACIn LFB 1984 components. 1986 5.1.5.1. Data Handling 1988 The LFB is expected to receive all types of Ethernet packets, via a 1989 singleton input known as "EtherPktsIn", which are usually output from 1990 an Ethernet encapsulation LFB, alongside with a metadatum indicating 1991 the physical port ID that the packet will go through(editorial note: 1992 need more discussion on the port ID being physical layer or L2 1993 layer). 1995 The LFB is defined with a singleton output. All Output packets are 1996 in Ethernet format, possibly with various Ethernet types, alongside 1997 with a metadatum indicating the physical port ID the packet is to go 1998 through. This output links to a downstream LFB that is usually an 1999 Ethernet physical LFB like EtherPHYcop LFB. 2001 This LFB can perform Ethernet layer flow control. This is usually 2002 implemented cooperatively by the EtherMACIn LFB and the EtherMACOut 2003 LFB. The flow control is further distinguished by Tx flow control 2004 and Rx flow control, separately for sending process and receiving 2005 process flow control. 2007 Note that as a base definition, functions like multiple virtual MAC 2008 layers are not supported in this LFB version. It may be supported in 2009 the future by defining a subclass or a new version of this LFB 2011 5.1.5.2. Components 2013 The AdminStatus component is defined for CE to administratively 2014 manage the status of the LFB. The CE may administratively startup or 2015 shutdown the LFB by changing the value of AdminStatus. The default 2016 value is set to 'Down'. Note that this component is defined as an 2017 alias of the AdminStatus component in the EtherMACIn LFB. This 2018 infers that an EtherMACOut LFB usually coexists with an EtherMACIn 2019 LFB, both of which share the same administrative status management by 2020 CE. Alias properties as defined in the ForCES FE model (RFC 5812) 2021 will be used by CE to declare the target component this alias refers, 2022 which include the target LFB class and instance IDs as well as the 2023 path to the target component. Whereas, these properties are set by 2024 CE only when a system runs, which are outside the XML definitions of 2025 this LFB. 2027 The MTU component defines the maximum transmission unit 2029 The TxFlowControl component defines whether the LFB is performing 2030 flow control on sending packets. The default value for is 'false'. 2031 Note that this component is defined as an alias of TxFlowControl 2032 component in the EtherMACIn LFB. 2034 The RxFlowControl component defines whether the LFB is performing 2035 flow control on receiving packets. The default value for is 'false'. 2036 Note that this component is defined as an alias of RxFlowControl 2037 component in the EtherMACIn LFB. 2039 A struct component, MACOutStats, defines a set of statistics for this 2040 LFB, including the number of transmitted packets and the number of 2041 dropped packets. 2043 5.1.5.3. Capabilities 2045 This LFB does not have a list of capabilities. 2047 5.1.5.4. Events 2049 This LFB does not have any events specified. 2051 5.2. IP Packet Validation LFBs 2053 The LFBs are defined to abstract IP packet validation process. An 2054 IPv4Validator LFB is specifically for IPv4 protocol validation and an 2055 IPv6Validator LFB for IPv6. 2057 5.2.1. IPv4Validator 2059 The IPv4Validator LFB performs IPv4 packets validation according to 2060 RFC 1812. 2062 5.2.1.1. Data Handling 2064 This LFB performs IPv4 validation according to RFC 1812. Then the 2065 IPv4 packet will be output to the corresponding port regarding of the 2066 validation result, whether the packet is a unicast or a multicast 2067 one, an exception has occurred or the validation failed. 2069 This LFB always expects, as input, packets which have been indicated 2070 as IPv4 packets by an upstream LFB, like an EtherClassifier LFB. 2071 There is no specific metadata expected by the input of the LFB. 2073 Note that, as a default provision of RFC 5812, in FE model, all 2074 metadata produced by upstream LFBs will pass through all downstream 2075 LFBs by default without being specified by input port or output port. 2076 Only those metadata that will be used(consumed) by an LFB will be 2077 explicitly marked in input of the LFB as expected metadata. For 2078 instance, in this LFB, even there is no specific metadata expected, 2079 metadata like PHYPortID produced by some upstream physical layer LFBs 2080 will always pass through this LFB. In some cases, if some component 2081 in the LFB may use the metadata, it actually still can use it 2082 regardless of whether the metadata has been expected or not. 2084 Four output ports are defined to output various validation results. 2086 All validated IPv4 unicast packets will be output at the singleton 2087 port known as "IPv4UnicastOut". All validated IPv4 multicast packets 2088 will be output at the singleton port known as "IPv4MulticastOut" 2089 port. There is no metadata specifically required to produce at these 2090 output ports. 2092 A singleton port known as "ExceptionOut" is defined to output packets 2093 which have been validated as exception packets. An exception ID 2094 metadatum is produced to indicate what has caused the exception. 2095 Currently defined exception types include: 2097 o Packet with destination address equal to 255.255.255.255 2099 o Packet with expired TTL 2101 o Packet with header length more than 5 words 2103 o Packet IP head including Router Alert options 2105 Note that, although TTL is checked in this LFB for validity, 2106 operations to TTL like TTL decreasing will be made only in a followed 2107 forwarding LFB. 2109 The final singleton port known as "FailOut" is defined for all 2110 packets which have failed the validation process. A validate error 2111 ID is associated to every failed packet to indicate the reason. 2112 Currently defined reasons include: 2114 o Packet size reported is less than 20 bytes 2116 o Packet with version is not IPv4 2117 o Packet with header length < 5 2119 o Packet with total length field < 20 2121 o Packet with invalid checksum 2123 o Packet with source address equal to 255.255.255.255 2125 o Packet with source address 0 2127 o Packet with source address of form {127, } 2129 o Packet with source address in Class E domain 2131 5.2.1.2. Components 2133 This LFB has only one struct component, the 2134 IPv4ValidatorStatisticsType, which defines a set of statistics for 2135 validation process, including the number of bad header packets, the 2136 number of bad total length packets, the number of bad TTL packets, 2137 and the number of bad checksum packets. 2139 5.2.1.3. Capabilities 2141 This LFB does not have a list of capabilities 2143 5.2.1.4. Events 2145 This LFB does not have any events specified. 2147 5.2.2. IPv6Validator 2149 The IPv6Validator LFB performs IPv6 packets validation according to 2150 RFC 2460. 2152 5.2.2.1. Data Handling 2154 This LFB performs IPv6 validation according to RFC 2460. Then the 2155 IPv6 packet will be output to the corresponding port regarding of the 2156 validation result, whether the packet is a unicast or a multicast 2157 one, an exception has occurred or the validation failed. 2159 This LFB always expects, as input, packets which have been indicated 2160 as IPv6 packets by an upstream LFB, like an EtherClassifier LFB. 2161 There is no specific metadata expected by the input of the LFB. 2163 Similar to the IPv4validator LFB, IPv6Validator has also defined four 2164 output ports to output packets for various validation results. 2166 All validated IPv6 unicast packets will be output at the singleton 2167 port known as "IPv6UnicastOut". All validated IPv6 multicast packets 2168 will be output at the singleton port known as "IPv6MulticastOut" 2169 port. There is no metadata specifically required to produce at these 2170 output ports. 2172 A singleton port known as "ExceptionOut" is defined to output packets 2173 which have been validated as exception packets. An exception ID 2174 metadata is produced to indicate what caused the exception. 2175 Currently defined exception types include: 2177 o Packet with hop limit to zero 2179 o Packet with a link-local destination address 2181 o Packet with a link-local source address 2183 o Packet with destination all-routers 2185 o Packet with destination all-nodes 2187 o Packet with next header set to Hop-by-Hop 2189 The final singleton port known as "FailOut" is defined for all 2190 packets which have failed the validation process. A validate error 2191 ID is associated to every failed packet to indicate the reason. 2192 Currently defined reasons include: 2194 o Packet size reported is less than 40 bytes 2196 o Packet with version is not IPv6 2198 o Packet with multicast source address (the MSB of the source 2199 address is 0xFF) 2201 o Packet with destination address set to 0 or ::1 2203 o Packet with source address set to loopback (::1). 2205 Note that in the base type library, definitions for exception ID and 2206 validate error ID metadata are applied to both IPv4Validator and 2207 IPv6Validator LFBs, i.e., the two LFBs share the same medadata 2208 definition, with different ID assignment inside. 2210 5.2.2.2. Components 2212 This LFB has only one struct component, the 2213 IPv6ValidatorStatisticsType, which defines a set of statistics for 2214 validation process, including the number of bad header packets, the 2215 number of bad total length packets, and the number of bad hop limit 2216 packets. 2218 5.2.2.3. Capabilities 2220 This LFB does not have a list of capabilities 2222 5.2.2.4. Events 2224 This LFB does not have any events specified. 2226 5.3. IP Forwarding LFBs 2228 IP Forwarding LFBs are specifically defined to abstract the IP 2229 forwarding processes. As definitions for a base LFB library, this 2230 document restricts its LFB definition scope for IP forwarding jobs 2231 only to IP unicast forwarding. LFBs for jobs like IP multicast may 2232 be defined in future versions of the document. 2234 A typical IP unicast forwarding job is usually realized by looking up 2235 some forwarding information table to find some next hop information, 2236 and then based on the next hop information, forwarding packets to 2237 specific output ports. It usually takes two steps to do so, firstly 2238 to look up a forwarding information table by means of Longest Prefix 2239 Matching(LPM) rule to find a next hop index, then to use the index to 2240 look up a next hop information table to find enough information to 2241 submit packets to output ports. This document abstracts the 2242 forwarding processes mainly based on the two steps model. However, 2243 there actually exists other models, like one which may only have a 2244 forwarding information base that have conjoined next hop information 2245 together with forwarding information. In this case, if ForCES 2246 technology is to be applied, some translation work will have to be 2247 done in FE to translate attributes defined by this document into real 2248 attributes the implementation has actually applied. 2250 Based on the IP forwarding abstraction, two kind of typical IP 2251 unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next 2252 hop application LFB. They are further distinguished by IPv4 and IPv6 2253 protocols. 2255 5.3.1. IPv4UcastLPM 2257 The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match 2258 (LPM) process.. 2260 This LFB also provides facilities to support users to implement 2261 equal-cost multi-path routing (ECMP) or reverse path forwarding 2262 (RPF). However, this LFB itself does not provide ECMP or RPF. To 2263 fully implement ECMP or RPF, additional specific LFBs, like a 2264 specific ECMP LFB or an RPF LFB, will have to be defined. This work 2265 may be done in the future version of the document. 2267 5.3.1.1. Data Handling 2269 This LFB performs the IPv4 unicast LPM table looking up. It always 2270 expects as input IPv4 unicast packets from one singleton input known 2271 as "PktsIn". Then the LFB uses the destination IPv4 address of every 2272 packet as index to look up the IPv4 prefix table and generate a hop 2273 selector as the matching result. This result will associate to the 2274 packet as a metadatum to output to downstream LFBs, and will usually 2275 be used there as an index to find more next hop information. 2277 Three singleton output ports are defined to output LPM results. 2279 The first singleton output known as "NormalOut", which will output 2280 IPv4 unicast packets that has passed the LPM lookup and got a hop 2281 selector as the lookup result. The hop selector is associated with 2282 the packet as a metadatum. Followed the normal output of the LPM LFB 2283 is usually a next hop application LFB, like an IPv4NextHop LFB. 2285 The second singleton output known as "ECMPOut" is defined to provide 2286 support for users wishing to implement ECMP. 2288 An ECMP flag is defined in the LPM table to enable the LFB to support 2289 ECMP. When a table entry is created with the flag set true, it 2290 indicates this table entry is for ECMP only. A packet, which has 2291 passed through this prefix lookup, will always output from "ECMPOut" 2292 output port, with the hop selector being its lookup result. The 2293 output will usually directly go to a downstream ECMP processing LFB, 2294 where the hop selector can usually further generate optimized one or 2295 multiple next hop routes by use of ECMP algorithms. 2297 A default route flag is defined in the LPM table to enable the LFB to 2298 support a default route, and loose RPF also. When set true, the 2299 table entry is identified a default route and as a forbidden route 2300 for RPF also. If a user wants to implement RPF on FE, a specific RPF 2301 LFB will have to be defined. In such RPF LFB, a component can be 2302 defined as an alias of the prefix table component of this LFB as 2303 described below. 2305 The final singleton output is known as "ExceptionOut" and is defined 2306 to allow exception packets to output here. Exceptions include cases 2307 like: 2309 o Packets can not find any routes in the prefix table. 2311 The upstream neighboring LFB of this LFB is usually IPv4Validator 2312 LFB. If RPF is to be adopted, the upstream can be an RPF LFB, when 2313 defined. 2315 The downstream neighboring LFB is usually IPv4NextHop LFB. If ECMP 2316 is adopted, the downstream can be an ECMP LFB, when defined. 2318 5.3.1.2. Components 2320 This LFB has two components. 2322 The IPv4PrefixTable component is defined as an array component of the 2323 LFB. Each row of the array contains an IPv4 adrress, a Prefix 2324 length, a Hop Selector, an ECMP flag and a Default Route flag. The 2325 LFB uses the destination IPv4 address of every input packet as index 2326 to look up this table to get a hop selector as the result. The ECMP 2327 flag is for the LFB to support ECMP.The default route flag is for the 2328 LFB to support a default route and for loose RPF. 2330 The IPv4UcastLPMStats component is a struct component which collects 2331 statistics information, including the total number of input packets 2332 received, the IPv4 packets forwarded by this LFB and the number of IP 2333 datagrams discarded due to no route found. 2335 5.3.1.3. Capabilities 2337 This LFB does not have a list of capabilities 2339 5.3.1.4. Events 2341 This LFB does not have any events specified. 2343 5.3.2. IPv4NextHop 2345 This LFB abstracts the process of selecting ipv4 next hop action. 2347 5.3.2.1. Data Handling 2349 The LFB abstracts the process of next hop information application to 2350 IPv4 packets. It receives an IPv4 packet with an associated next hop 2351 ID, and uses the ID to look up a next hop table to find an 2352 appropriate output port from the LFB. 2354 The LFB is expected to receive unicast IPv4 packets, via a singleton 2355 input known as "PcktsIn" along with a HopSelector metadata which is 2356 used as an index to lookup the NextHop table. Data processing 2357 involves the forwarding TTL decrement and checksum recalculation. 2359 Two output ports are defined to output results. 2361 The first output is a group output port known as "SuccessOut". On 2362 successful data processing the packet is sent out an LFB-port from 2363 within the LFB port group as selected by the LFBOutputSelectIndex 2364 value of the matched table entry. The packet is sent to a downstream 2365 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. 2367 The second output is a singleton output port known as "ExceptionOut", 2368 which will output packets for which the data processing failed, along 2369 with an additional ExceptionID metadata to indicate what caused the 2370 exception. Currently defined exception types include: 2372 o The HopSelector is invalid 2374 o The MTU for outgoing interface is less than the packet size 2376 o ICMP packet needs to be generated 2378 Downstream neighboring LFB instances could be either a 2379 BasicMetadataDispatch type, used to fanout to different LFB instances 2380 or a media encapsulation related type, such as an EtherEncap type or 2381 a RedirectOut type. For example, there are Ethernet and other tunnel 2382 Encapsulation, then BasicMetadataDispatch can use the L3PortID 2383 metadata to dispatch packets to different Encapsulator. 2385 5.3.2.2. Components 2387 This LFB has only one component named IPv4NextHopTable which is 2388 defined as an array. Each row of the array is a struct containing: 2390 o The L3PortID, which is the ID of the Logical Output Port that is 2391 passed onto the neighboring LFB instance. This ID indicates what 2392 port to the neighbor is as defined by L3. 2394 o MTU, the Maximum Transmission Unit for the outgoing port. 2396 o NextHopIPAddr, the IPv4 next hop Address. 2398 o MediaEncapInfoIndex, the index we pass onto the neighboring LFB 2399 instance. This index is used to lookup a table (typically media 2400 encapsulatation related) further downstream. The CE sets it to a 2401 value that is not allocated in downstream LFB tables. (If a 2402 downstream LFB lookup fails to find it, it indicates some other 2403 way to resolve it may be needed.) 2405 o LFBOutputSelectIndex, the LFB Group output port index to select 2406 downstream LFB port. This index exactly is the FromPortIndex for 2407 the port group "SuccessOut" in the table LFBTopology of FEObject 2408 LFB as defined for the Nexthop LFB. 2410 5.3.2.3. Capabilities 2412 This LFB does not have a list of capabilities 2414 5.3.2.4. Events 2416 This LFB does not have any events specified. 2418 5.3.3. IPv6UcastLPM 2420 The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match 2421 (LPM) process. The definition of this LFB is similar to the 2422 IPv4UcastLPM LFB except that all IP addresses refer to IPv6 2423 addresses. 2425 This LFB also provides facilities to support users to implement 2426 equal-cost multi-path routing (ECMP) or reverse path forwarding 2427 (RPF). However, this LFB itself does not provide ECMP or RPF. To 2428 fully implement ECMP or RPF, additional specific LFBs, like a 2429 specific ECMP LFB or an RPF LFB, will have to be defined. This work 2430 may be done in the future version of the document. 2432 5.3.3.1. Data Handling 2434 This LFB performs the IPv6 unicast LPM table looking up. It always 2435 expects as input IPv6 unicast packets from one singleton input known 2436 as "PktsIn". Then the LFB uses the destination IPv6 address of every 2437 packet as index to look up the IPv6 prefix table and generate a hop 2438 selector as the matching result. This result will associate to the 2439 packet as a metadatum to output to downstream LFBs, and will usually 2440 be used there as an index to find more next hop information. 2442 Three singleton output ports are defined to output LPM results. 2444 The first singleton output known as "NormalOut", which will output 2445 IPv6 unicast packets that has passed the LPM lookup and got a hop 2446 selector as the lookup result. The hop selector is associated with 2447 the packet as a metadatum. Followed the normal output of the LPM LFB 2448 is usually a next hop application LFB, like an IPv6NextHop LFB. 2450 The second singleton output known as "ECMPOut" is defined to provide 2451 support for users wishing to implement ECMP. 2453 An ECMP flag is defined in the LPM table to enable the LFB to support 2454 ECMP. When a table entry is created with the flag set true, it 2455 indicates this table entry is for ECMP only. A packet, which has 2456 passed through this prefix lookup, will always output from "ECMPOut" 2457 output port, with the hop selector being its lookup result. The 2458 output will usually directly go to a downstream ECMP processing LFB, 2459 where the hop selector can usually further generate optimized one or 2460 multiple next hop routes by use of ECMP algorithms. 2462 A default route flag is defined in the LPM table to enable the LFB to 2463 support a default route, and loose RPF also. When set true, the 2464 table entry is identified a default route and as a forbidden route 2465 for RPF also. If a user wants to implement RPF on FE, a specific RPF 2466 LFB will have to be defined. In such RPF LFB, a component can be 2467 defined as an alias of the prefix table component of this LFB as 2468 described below. 2470 The final singleton output is known as "ExceptionOut" and is defined 2471 to allow exception packets to output here. Exceptions include cases 2472 like: 2474 o Packets can not find any routes in the prefix table. 2476 The upstream neighboring LFB of this LFB is usually IPv6Validator 2477 LFB. If RPF is to be adopted, the upstream can be an RPF LFB, when 2478 defined. 2480 The downstream neighboring LFB is usually an IPv6NextHop LFB. If 2481 ECMP is adopted, the downstream can be an ECMP LFB, when defined. 2483 5.3.3.2. Components 2485 This LFB has two components. 2487 The IPv6PrefixTable component is defined as an array component of the 2488 LFB. Each row of the array contains an IPv6 adrress, a Prefix 2489 length, a Hop Selector, an ECMP flag and a Default Route flag. The 2490 LFB uses the destination IPv6 address of every input packet as index 2491 to look up this table to get a hop selector as the result. The ECMP 2492 flag is for the LFB to support ECMP. The default route flag is for 2493 the LFB to support a default route and for loose RPF. 2495 The IPv6UcastLPMStats component is a struct component which collects 2496 statistics information, including the total number of input packets 2497 received, the IPv6 packets forwarded by this LFB and the number of IP 2498 datagrams discarded due to no route found. 2500 5.3.3.3. Capabilities 2502 This LFB does not have a list of capabilities 2504 5.3.3.4. Events 2506 This LFB does not have any events specified. 2508 5.3.4. IPv6NextHop 2510 This LFB abstracts the process of selecting IPv6 next hop action. 2512 5.3.4.1. Data Handling 2514 The LFB abstracts the process of next hop information application to 2515 IPv6 packets. It receives an IPv6 packet with an associated next hop 2516 ID, and uses the ID to look up a next hop table to find an 2517 appropriate output port from the LFB. 2519 The LFB is expected to receive unicast IPv6 packets, via a singleton 2520 input known as "PcktsIn" along with a HopSelector metadata which is 2521 used as an index to lookup the NextHop table. 2523 Two output ports are defined to output results. 2525 The first output is a group output port known as "SuccessOut". On 2526 successful data processing the packet is sent out an LFB-port from 2527 within the LFB port group as selected by the LFBOutputSelectIndex 2528 value of the matched table entry. The packet is sent to a downstream 2529 LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. 2531 The second output is a singleton output port known as "ExceptionOut", 2532 which will output packets for which the data processing failed, along 2533 with an additional ExceptionID metadata to indicate what caused the 2534 exception. Currently defined exception types include: 2536 o The HopSelector is invalid 2538 o The MTU for outgoing interface is less than the packet size 2540 o ICMP packet needs to be generated 2542 Downstream neighboring LFB instances could be either a 2543 BasicMetadataDispatch type, used to fanout to different LFB instances 2544 or a media encapsulatation related type, such as an EtherEncap type 2545 or a RedirectOut type. For example, there are Ethernet and other 2546 tunnel Encapsulation, then BasicMetadataDispatch can use the L3PortID 2547 metadata to dispatch packets to different Encapsulator. 2549 5.3.4.2. Components 2551 This LFB has only one component named IPv6NextHopTable which is 2552 defined as an array. Each row of the array is a struct containing: 2554 o The L3PortID, which is the ID of the Logical Output Port that is 2555 passed onto the neighboring LFB instance. This ID indicates what 2556 port to the neighbor is as defined by L3. 2558 o MTU, the Maximum Transmission Unit for the outgoing port. 2560 o NextHopIPAddr, the IPv6 next hop Address. 2562 o MediaEncapInfoIndex, the index we pass onto the neighboring LFB 2563 instance. This index is used to lookup a table (typically media 2564 encapsulatation related) further downstream. The CE sets it to a 2565 value that is not allocated in downstream LFB tables. (If a 2566 downstream LFB lookup fails to find it, it indicates some other 2567 way to resolve it may be needed.) 2569 o LFBOutputSelectIndex, the LFB Group output port index to select 2570 downstream LFB port. This index exactly is the FromPortIndex for 2571 the port group "SuccessOut" in the table LFBTopology of FEObject 2572 LFB as defined for the Nexthop LFB. 2574 5.3.4.3. Capabilities 2576 This LFB does not have a list of capabilities 2578 5.3.4.4. Events 2580 This LFB does not have any events specified. 2582 5.4. Redirect LFBs 2584 Redirect LFBs abstract data packets transportation process between CE 2585 and FE. Some packets output from some LFBs may have to be delivered 2586 to CE for further processing, and some packets generated by CE may 2587 have to be delivered to FE and further to some specific LFBs for data 2588 path processing. According to RFC 5810 [RFC5810], data packets and 2589 their associated metadata are encapsulated in ForCES redirect message 2590 for transportation between CE and FE. We define two LFBs to abstract 2591 the process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an 2592 LFB topology of an FE, only one RedirectIn LFB instance and one 2593 RedirectOut LFB instance exist. 2595 5.4.1. RedirectIn 2597 RedirectIn LFB abstracts the process for the CE to inject data 2598 packets into the FE data path. 2600 5.4.1.1. Data Handling 2602 A RedirectIn LFB abstracts the process for the CE to inject data 2603 packets into the FE LFB topology so as to input data packets into FE 2604 data paths. From LFB topology point of view, the RedirectIn LFB acts 2605 as a source point for data packets coming from CE, therefore the 2606 RedirectIn LFB is defined with only one output, while without any 2607 input. 2609 The RedirectIn LFB has only one output defined as a group output 2610 known as "PktsOut". Packets produced by this output will have 2611 arbitrary frame types decided by the CE which generated the packets. 2612 Possible frames may include IPv4, IPv6, or ARP protocol packets. The 2613 CE may associate some metadata to indicate the frame types and may 2614 also associate other metadata to indicate various information on the 2615 packets. Among them, there MUST exist a 'RedirectIndex' metadata, 2616 which is an integer acting as an index. When the CE transmits the 2617 metadata along with the packet to a RedirectIn LFB, the LFB will read 2618 the RedirectIndex metadata and output the packet to one of its group 2619 output port instance, whose port index is indicated by the metadata. 2621 All metadata from the CE other than the 'RedirectIndex' metadata will 2622 output from the RedirectIn LFB along with their binding packets. 2623 Note that, a packet without a 'RedirectIndex' metadata associated 2624 will be dropped by the LFB. 2626 5.4.1.2. Components 2628 There are no components defined for the current version of RedirectIn 2629 LFB. 2631 5.4.1.3. Capabilities 2633 This LFB does not have a list of capabilities 2635 5.4.1.4. Events 2637 This LFB does not have any events specified. 2639 5.4.2. RedirectOut 2641 RedirectOut LFB abstracts the process for LFBs in the FE to deliver 2642 data packets to the CE. 2644 5.4.2.1. Data Handling 2646 A RedirectOut LFB abstracts the process for LFBs in the FE to deliver 2647 data packets to the CE. From the LFB's topology point of view, the 2648 RedirectOut LFB acts as a sink point for data packets going to the 2649 CE, therefore the RedirectOut LFB is defined with only one input, 2650 while without any output. 2652 The RedirectOut LFB has only one singleton input known as "PktsIn", 2653 but is capable of receiving packets from multiple LFBs by 2654 multiplexing this input. The input expects any kind of frame type 2655 therefore the frame type has been specified as arbitrary and also all 2656 types of metadata are expected. All metadata associated with the 2657 input packets will be delivered to CE via the ForCES protocol 2658 redirect message [RFC5810]. 2660 5.4.2.2. Components 2662 There are no components defined for the current version of 2663 RedirectOut LFB. 2665 5.4.2.3. Capabilities 2667 This LFB does not have a list of capabilities 2669 5.4.2.4. Events 2671 This LFB does not have any events specified. 2673 5.5. General Purpose LFBs 2675 5.5.1. BasicMetadataDispatch 2677 A basic medatata dispatch LFB is defined to abstract the process in 2678 which a packet is dispatched to some path based on its associated 2679 metadata value. 2681 5.5.1.1. Data Handling 2683 The BasicMetadataDispatch LFB provides the function to dispatch input 2684 packets to a group output according to a metadata and a dispatch 2685 table. 2687 The BasicMetadataDispatch has only one singleton input known as 2688 "PktsIn" and expects any kind of frame type, therefore it has been 2689 specified as arbitrary, along with a metadata that will be used by 2690 the LFB to do the dispatch. If a packet is not associated with such 2691 a metadata, the packet will be dropped inside the LFB. 2693 The BasicMetadataDispatch LFB has only one output defined as a group 2694 output known as "PktsOut". A packet, if it is associated with a 2695 metadata with the metadata ID, will be output to the group port 2696 instance with the index corresponding to the metadata value in the 2697 Metadata Dispatch table. Currently the BasicMetadataDispatch only 2698 allows an interger value for the metadata to be used for dispatch. 2700 The BasicMetadataDispatch LFB is currently defined with only one 2701 metadata adopted for dispatch, i.e., the metadata ID in the dispatch 2702 table is always the same for all table rows. 2704 A more complex metadata dispatch LFB may be defined in future version 2705 of the library. In that LFB, multiple tuples of metadata may be 2706 adopted to dispatch packets. 2708 5.5.1.2. Components 2710 This LFB has only one component named MetadataDispatchTable which is 2711 defined as an array. Each row of the array is a struct containing a 2712 Metadata ID, a Metadata value and the OutputIndex to selectt the 2713 output port from the group. 2715 5.5.1.3. Capabilities 2717 This LFB does not have a list of capabilities 2719 5.5.1.4. Events 2721 This LFB does not have any events specified. 2723 5.5.2. GenericScheduler 2725 This is a preliminary generic scheduler LFB for abstracting a simple 2726 scheduling process. 2728 5.5.2.1. Data Handling 2730 There exist various kinds of scheduling strategies with various 2731 implementations. As a base LFB library, this document only defines a 2732 preliminary generic scheduler LFB for abstracting a simple scheduling 2733 process. Users may use this LFB as a basic scheduler LFB to further 2734 construct more complex scheduler LFBs by means of inheritance as 2735 described in RFC 5812 [RFC5812]. 2737 Packets of any arbitrary frame type are received via a group input 2738 known as "PktsIn" with no additional metadata expected. This group 2739 input is capable of multiple input port instances. Each port 2740 instance may be connected to different upstream LFB output. 2742 Multiple queues reside at the input side, with every input port 2743 instance connected to one queue. Every queue is marked with a queue 2744 ID, and the queue ID is exactly the same as the index of 2745 corresponding input port instance. Scheduling disciplines are 2746 applied to all queues and also all packets in the queues. 2748 Scheduled packets are output from a singleton output port of the LFB 2749 knows as "PktsOut" with no corresponding metadata. 2751 More complex scheduler LFBs may be defined with more complex 2752 scheduling disciplines by succeeding this LFB. For instance, a 2753 priority scheduler LFB may be defined only by inheriting this LFB and 2754 defining a component to indicate priorities for all input queues. 2756 5.5.2.2. Components 2758 The QueueCount component is defined to specify the number of queues 2759 to be scheduled. 2761 The SchedulingDiscipline component is for the CE to specify a 2762 scheduling discipline to the LFB. Currently defined scheduling 2763 disciplines only include FIFO and Round Robin (RR). When a FIFO 2764 discipline is applied, it is requires that there is only one input 2765 port instance for the group input. If the user accidentally defines 2766 multiple input port instances for FIFO scheduling, only packets in 2767 the input port with lowest port index will be scheduled to output 2768 port, and all packets in other input port instances will just 2769 ignored. Note that if the generic scheduler LFB is defined only one 2770 input port instance, the default scheduling discipline is FIFO. If 2771 the LFB is defined with more than one input port instances, the 2772 default scheduling discipline is round robin (RR). 2774 The CurrentQueueDepth component is defined to allow CE to query every 2775 queue status of the scheduler. It is an array component and each row 2776 of the array is a struct containing a queue ID, the queue depth in 2777 packets and the queue depth in bytes. Using the queue ID as the 2778 index, the CE can query every queue for its used length in unit of 2779 packets or bytes. 2781 5.5.2.3. Capabilities 2783 Three capabilities are currently defined for the GenericScheduler. 2785 o A queue number limit, which specify the limit of the maximum 2786 supported number of queues, which is also the maximum number of 2787 input port instances. 2789 o The supported scheduling disciplines types by the FE, currently 2790 maximum 6. 2792 o The queue length limit providing the storage ability for every 2793 queue. 2795 5.5.2.4. Events 2797 This LFB does not have any events specified. 2799 6. XML for LFB Library 2801 2802 2805 2806 2807 2808 EtherPHYCop 2809 The LFB describes an Ethernet port abstracted at 2810 physical layer.It limits its physical media to copper. 2811 Multiple virtual PHYs isn't supported in this LFB version. 2812 2813 1.0 2814 2815 2816 EtherPHYIn 2817 The input port of the EtherPHYCop LFB. It 2818 expects any kind of Ethernet frame. 2819 2820 2821 EthernetAll 2822 2823 2824 2825 2826 2827 2828 EtherPHYOut 2829 The output port of the EtherPHYCop LFB. It 2830 can produce any kind of Ethernet frame and along with 2831 the frame passes the ID of the Physical Port as 2832 metadata to be used by the next LFBs. 2833 2834 2835 EthernetAll 2836 2837 2838 PHYPortID 2839 2840 2841 2842 2843 2844 2845 PHYPortID 2846 The ID of the physical port that this LFB 2847 handles. 2848 uint32 2849 2850 2851 AdminStatus 2852 Admin status of the LFB 2853 PortStatusValues 2854 2 2855 2856 2857 OperStatus 2858 Operational status of the LFB. 2859 PortStatusValues 2860 2861 2862 AdminLinkSpeed 2863 The link speed that the admin has requested. 2864 2865 LANSpeedType 2866 0x00000005 2867 2868 2869 OperLinkSpeed 2870 The actual operational link speed. 2871 LANSpeedType 2872 2873 2874 AdminDuplexMode 2875 The duplex mode that the admin has requested. 2876 2877 DuplexType 2878 0x00000001 2879 2880 2881 OperDuplexMode 2882 The actual duplex mode. 2883 DuplexType 2884 2885 2886 CarrierStatus 2887 The status of the Carrier. Whether the port 2888 is linked with an operational connector. 2889 boolean 2890 false 2891 2892 2893 2894 2895 SupportedLinkSpeed 2896 Supported Link Speeds 2897 2898 LANSpeedType 2899 2900 2901 2902 SupportedDuplexMode 2903 Supported Duplex Modes 2904 2905 DuplexType 2906 2907 2908 2909 2910 2911 PHYPortStatusChanged 2912 When the status of the Physical port is 2913 changed,the LFB sends the new status. 2914 2915 OperStatus 2916 2917 2918 2919 2920 OperStatus 2921 2922 2923 2924 2925 LinkSpeedChanged 2926 When the operational speed of the link 2927 is changed, the LFB sends the new operational link 2928 speed. 2929 2930 OperLinkSpeed 2931 2932 2933 2934 2935 OperLinkSpeed 2936 2937 2938 2939 2940 DuplexModeChanged 2941 When the operational duplex mode 2942 is changed, the LFB sends the new operational mode. 2943 2944 2945 OperDuplexMode 2946 2947 2948 2949 2950 OperDuplexMode 2951 2952 2953 2954 2955 2956 2957 EtherMACIn 2958 An LFB abstracts an Ethernet port at MAC data link 2959 layer. It specifically describes Ethernet processing functions 2960 like MAC address locality check, deciding if the Ethernet 2961 packets should be bridged, provide Ethernet layer flow control, 2962 etc.Multiple virtual MACs isn't supported in this LFB 2963 version. 2964 1.0 2965 2966 2967 EtherMACIn 2968 The input port of the EtherMACIn. It 2969 expects any kind of Ethernet frame. 2970 2971 2972 EthernetAll 2973 2974 2975 PHYPortID 2976 2977 2978 2979 2980 2981 2982 NormalPathOut 2983 The normal output port of the EtherMACIn. 2984 It can produce any kind of Ethernet frame and along 2985 with the frame passes the ID of the Physical Port as 2986 metadata to be used by the next LFBs. 2987 2988 2989 EthernetAll 2991 2992 2993 PHYPortID 2994 2995 2996 2997 2998 L2BridgingPathOut 2999 The Bridging Output Port of the EtherMACIn. 3000 It can produce any kind of Ethernet frame and along 3001 with the frame passes the ID of the Physical Port as 3002 metadata to be used by the next LFBs. 3003 3004 3005 EthernetAll 3006 3007 3008 PHYPortID 3009 3010 3011 3012 3013 3014 3015 AdminStatus 3016 Admin status of the port 3017 PortStatusValues 3018 2 3019 3020 3021 LocalMACAddresses 3022 Local Mac addresses 3023 3024 IEEEMAC 3025 3026 3027 3028 L2BridgingPathEnable 3029 Is the LFB doing L2 Bridging? 3030 boolean 3031 false 3032 3033 3034 PromiscuousMode 3035 Is the LFB in Promiscuous Mode? 3036 boolean 3037 false 3038 3039 3040 TxFlowControl 3041 Transmit flow control 3042 boolean 3043 false 3044 3045 3046 RxFlowControl 3047 Receive flow control 3048 boolean 3049 false 3050 3051 3052 MACInStats 3053 MACIn statistics 3054 MACInStatsType 3055 3056 3057 3058 3059 EtherClassifier 3060 This LFB abstracts the process to decapsulate 3061 Ethernet packets and classify the data packets into 3062 various network layer data packets according to information 3063 included in the Ethernet packets headers. 3064 1.0 3065 3066 3067 EtherPktsIn 3068 Input port for data packet. 3069 3070 3071 EthernetAll 3072 3073 3074 PHYPortID 3075 3076 LogicalPortID 3077 3078 3079 3080 3081 3082 3083 ClassifyOut 3084 Output port for classification. 3085 3086 3087 Arbitrary 3088 3089 3090 PHYPortID 3091 SrcMAC 3092 DstMAC 3093 EtherType 3094 VlanID 3095 VlanPriority 3096 3097 3098 3099 3100 3101 3102 EtherDispatchTable 3103 Ether classify dispatch table 3104 EtherDispatchTableType 3105 3106 3107 VlanInputTable 3108 Vlan input table 3109 VlanInputTableType 3110 3111 3112 EtherClassifyStats 3113 Ether classify statistic table 3114 EtherClassifyStatsTableType 3115 3116 3117 3118 3119 EtherEncap 3120 This LFB abstracts the process to encapsulate IP 3121 packets to Ethernet packets according to the L2 information. 3122 3123 1.0 3124 3125 3126 EncapIn 3127 A Single Packet Input 3128 3129 3130 IPv4 3131 IPv6 3132 3133 3134 MediaEncapInfoIndex 3135 3136 VlanPriority 3137 3138 3139 3140 3141 3142 3143 SuccessOut 3144 Output port for Packets which have found 3145 Ethernet L2 information and have been successfully 3146 encapsulated to an Ethernet packet. 3147 3148 3149 IPv4 3150 IPv6 3151 3152 3153 L2PortID 3154 3155 3156 3157 3158 ExceptionOut 3159 All packets that fail with the other 3160 operations in this LFB are output via this port. 3161 3162 3163 3164 IPv4 3165 IPv6 3166 3167 3168 ExceptionID 3169 MediaEncapInfoIndex 3170 VlanPriority 3171 3172 3173 3174 3175 3176 3177 EncapTable 3178 Ethernet Encapsulation table. 3179 EncapTableType 3180 3181 3182 3183 3184 EtherMACOut 3185 EtherMACOut LFB abstracts an Ethernet port at MAC 3186 data link layer. It specifically describes Ethernet packet 3187 output process. Ethernet output functions are closely related 3188 to Ethernet input functions, therefore some components 3189 defined in this LFB are actually alias of EtherMACIn LFB. 3190 3191 1.0 3192 3193 3194 EtherPktsIn 3195 The Input Port of the EtherMACIn. It expects 3196 any kind of Ethernet frame. 3197 3198 3199 EthernetAll 3200 3201 3202 PHYPortID 3203 3204 3205 3206 3207 3208 3209 EtherMACOut 3210 The Normal Output Port of the EtherMACOut. It 3211 can produce any kind of Ethernet frame and along with 3212 the frame passes the ID of the Physical Port as 3213 metadata to be used by the next LFBs. 3214 3215 3216 EthernetAll 3217 3218 3219 PHYPortID 3220 3221 3222 3223 3224 3225 3226 AdminStatus 3227 Admin status of the port. It is the alias of 3228 "AdminStatus" component defined in EtherMACIn. 3229 3230 PortStatusValues 3232 3233 3234 MTU 3235 Maximum transmission unit. 3236 uint32 3237 3238 3239 TxFlowControl 3240 Transmit flow control. It is the alias of 3241 "TxFlowControl" component defined in EtherMACIn. 3242 3243 boolean 3244 3245 3246 RxFlowControl 3247 Receive flow control. It is the alias of 3248 "RxFlowControl" component defined in EtherMACIn. 3249 3250 boolean 3251 3252 3253 MACOutStats 3254 MACOut statistics 3255 MACOutStatsType 3256 3257 3258 3259 3260 IPv4Validator 3261 An LFB that performs IPv4 packets validation 3262 according to RFC1812. At the same time, ipv4 unicast and 3263 multicast are classified in this LFB. 3264 1.0 3265 3266 3267 ValidatePktsIn 3268 Input port for data packet. 3269 3270 3271 Arbitrary 3272 3273 3274 3275 3276 3277 3278 IPv4UnicastOut 3279 Output for IPv4 unicast packet. 3280 3281 3282 IPv4Unicast 3283 3284 3285 3286 3287 IPv4MulticastOut 3288 Output for IPv4 multicast packet. 3289 3290 3291 IPv4Multicast 3292 3293 3294 3295 3296 ExceptionOut 3297 Output for exception packet. 3298 3299 3300 IPv4 3301 3302 3303 ExceptionID 3304 3305 3306 3307 3308 FailOut 3309 Output for failed validation packet. 3310 3311 3312 3313 IPv4 3314 3315 3316 ValidateErrorID 3317 3318 3319 3320 3321 3322 3323 IPv4ValidatorStats 3324 IPv4 validator statistics information. 3325 3326 IPv4ValidatorStatsType 3327 3329 3330 3331 3332 IPv6Validator 3333 An LFB that performs IPv6 packets validation 3334 according to RFC2460. At the same time, ipv6 unicast and 3335 multicast are classified in this LFB. 3336 1.0 3337 3338 3339 ValidatePktsIn 3340 Input port for data packet. 3341 3342 3343 Arbitrary 3344 3345 3346 3347 3348 3349 3350 IPv6UnicastOut 3351 Output for IPv6 unicast packet. 3352 3353 3354 IPv6Unicast 3355 3356 3357 3358 3359 IPv6MulticastOut 3360 Output for IPv6 multicast packet. 3361 3362 3363 IPv6Multicast 3364 3365 3366 3367 3368 ExceptionOut 3369 Output for exception packet. 3370 3371 3372 IPv6 3373 3374 3375 ExceptionID 3376 3378 3379 3380 3381 FailOut 3382 Output for failed validation packet. 3383 3384 3385 3386 IPv6 3387 3388 3389 ValidateErrorID 3390 3391 3392 3393 3394 3395 3396 IPv6ValidatorStats 3397 IPv6 validator statistics information. 3398 3399 IPv6ValidatorStatsType 3400 3401 3402 3403 3404 IPv4UcastLPM 3405 An LFB that performs IPv4 Longest Prefix Match 3406 Lookup.It is defined to provide some facilities to support 3407 users to implement equal-cost multi-path routing(ECMP) or 3408 reverse path forwarding (RPF). 3409 1.0 3410 3411 3412 PktsIn 3413 A Single Packet Input 3414 3415 3416 IPv4Unicast 3417 3418 3419 3420 3421 3422 3423 NormalOut 3424 This output port is connected with 3425 IPv4NextHop LFB 3426 3427 3428 IPv4Unicast 3429 3430 3431 HopSelector 3432 3433 3434 3435 3436 ECMPOut 3437 This output port is connected with ECMP LFB, 3438 if there is ECMP LFB in the FE. 3439 3440 3441 IPv4Unicast 3442 3443 3444 HopSelector 3445 3446 3447 3448 3449 ExceptionOut 3450 The output for the packet if an exception 3451 occurs 3452 3453 3454 IPv4Unicast 3455 3456 3457 ExceptionID 3458 3459 3460 3461 3462 3463 3464 IPv4PrefixTable 3465 The IPv4 prefix table. 3466 IPv4PrefixTableType 3467 3468 3469 IPv4UcastLPMStats 3470 Statistics for IPv4 Unicast Longest Prefix 3471 Match 3472 IPv4UcastLPMStatsType 3473 3475 3476 3477 3478 IPv6UcastLPM 3479 An LFB that performs IPv6 Longest Prefix Match 3480 Lookup.It is defined to provide some facilities to support 3481 users to implement equal-cost multi-path routing(ECMP) or 3482 reverse path forwarding (RPF). 3483 1.0 3484 3485 3486 PktsIn 3487 A Single Packet Input 3488 3489 3490 IPv6Unicast 3491 3492 3493 3494 3495 3496 3497 NormalOut 3498 This output port is connected with 3499 IPv6NextHop LFB 3500 3501 3502 IPv6Unicast 3503 3504 3505 HopSelector 3506 3507 3508 3509 3510 ECMPOut 3511 This output port is connected with ECMP LFB, 3512 if there is ECMP LFB in the FE. 3513 3514 3515 IPv6Unicast 3516 3517 3518 HopSelector 3519 3520 3521 3522 3523 ExceptionOut 3524 The output for the packet if an exception 3525 occurs 3526 3527 3528 IPv6Unicast 3529 3530 3531 ExceptionID 3532 3533 3534 3535 3536 3537 3538 IPv6PrefixTable 3539 The IPv6 prefix table. 3540 IPv6PrefixTableType 3541 3542 3543 IPv6UcastLPMStats 3544 Statistics for IPv6 Unicast Longest Prefix 3545 Match 3546 IPv6UcastLPMStatsType 3547 3548 3549 3550 3551 IPv4NextHop 3552 This LFB abstracts the process of selecting ipv4 3553 next hop action. It receives an IPv4 packet with an 3554 associated next hop ID, and uses the ID to look up a next 3555 hop table to find an appropriate output port from the LFB. 3556 3557 1.0 3558 3559 3560 PktsIn 3561 A Single Packet Input 3562 3563 3564 IPv4Unicast 3565 3566 3567 HopSelector 3568 3569 3570 3572 3573 3574 3575 SuccessOut 3576 The output for the packet if it is valid to be 3577 forwarded 3578 3579 3580 IPv4Unicast 3581 3582 3583 L3PortID 3584 NextHopIPv4Addr 3585 3586 MediaEncapInfoIndex 3587 3588 3589 3590 3591 ExceptionOut 3592 The output for the packet if an exception 3593 occurs 3594 3595 3596 IPv4Unicast 3597 3598 3599 ExceptionID 3600 3601 3602 3603 3604 3605 3606 IPv4NextHopTable 3607 The next hop table. 3608 IPv4NextHopTableType 3609 3610 3611 3612 3613 IPv6NextHop 3614 The LFB abstracts the process of next hop 3615 information application to IPv6 packets. It receives an IPv4 3616 packet with an associated next hop ID, and uses the ID to 3617 look up a next hop table to find an appropriate output port 3618 from the LFB.. 3619 1.0 3620 3621 3622 PktsIn 3623 A single packet input. 3624 3625 3626 IPv6Unicast 3627 3628 3629 HopSelector 3630 3631 3632 3633 3634 3635 3636 SuccessOut 3637 The output for the packet if it is valid to 3638 be forwarded 3639 3640 3641 IPv6Unicast 3642 3643 3644 L3PortID 3645 NextHopIPv6Addr 3646 3647 MediaEncapInfoIndex 3648 3649 3650 3651 3652 ExceptionOut 3653 The output for the packet if an exception 3654 occurs 3655 3656 3657 IPv6Unicast 3658 3659 3660 ExceptionID 3661 3662 3663 3664 3665 3666 3667 IPv6NextHopTable 3668 The next hop table. 3669 IPv6NextHopTableType 3670 3671 3672 3673 3674 RedirectIn 3675 The RedirectIn LFB abstracts the process for CE to 3676 inject data packets into FE LFB topology, so as to input data 3677 packets into FE data paths. CE may associate some 3678 metadata to data packets to indicate various information on 3679 the packets. Among them, there MUST exist a 'RedirectIndex' 3680 metadata, which is an integer acting as an output port index. 3681 3682 1.0 3683 3684 3685 PktsOut 3686 This output group sends the redirected packet 3687 in the data path. 3688 3689 3690 Arbitrary 3691 3692 3693 3694 3695 3696 3697 RedirectOut 3698 The LFB abstracts the process for LFBs in 3699 FE to deliver data packets to CE. All metadata 3700 associated with the input packets will be delivered to CE 3701 via the redirect message of ForCES protocol [RFC5810]. 3702 3703 1.0 3704 3705 3706 PktsIn 3707 This input receives packets to send to 3708 the CE. 3709 3710 3711 Arbitrary 3712 3713 3714 3715 3717 3718 3719 BasicMetadataDispatch 3720 This LFB provides the function to dispatch input 3721 packets to a group output according to a metadata and a 3722 dispatch table.This LFB currently only allow a metadata with 3723 an interger value to be used for dispatch. 3724 1.0 3725 3726 3727 PktsIn 3728 Input port for data packet. 3729 3730 3731 Arbitrary 3732 3733 3734 Arbitrary 3735 3736 3737 3738 3739 3740 3741 PktsOut 3742 Data packet output 3743 3744 3745 Arbitrary 3746 3747 3748 3749 3750 3751 3752 MetadataDispatchTable 3753 Metadata dispatch table. 3754 MetadataDispatchTableType 3755 3756 3757 3758 3759 GenericScheduler 3760 This is a preliminary generic scheduler LFB for 3761 abstracting a simple scheduling process.Users may use this 3762 LFB as a basic scheduler LFB to further construct more 3763 complex scheduler LFBs by means of inheritance as described 3764 in RFC 5812. 3766 1.0 3767 3768 3769 PktsIn 3770 Input port for data packet. 3771 3772 3773 Arbitrary 3774 3775 3776 3777 3778 3779 3780 PktsOut 3781 Data packet output. 3782 3783 3784 Arbitrary 3785 3786 3787 3788 3789 3790 3791 QueueCount 3792 The number of queues to be scheduled. 3793 3794 uint32 3795 3796 3797 SchedulingDiscipline 3798 the Scheduler discipline. 3799 SchdDisciplineType 3800 3801 3802 CurrentQueueDepth 3803 Current Depth of all queues 3804 QueueDepthTableType 3805 3806 3807 3808 3809 QueueLenLimit 3810 Maximum length of each queue,the unit is 3811 byte. 3812 uint32 3813 3814 3815 QueueScheduledLimit 3816 Max number of queues that can be scheduled 3817 by this scheduluer. 3818 uint32 3819 3820 3821 DisciplinesSupported 3822 the scheduling disciplines supported. 3823 3824 3825 SchdDisciplineType 3826 3827 3828 3829 3830 3831 3832 7. LFB Class Use Cases 3834 This section demonstrates examples on how the LFB classes defined by 3835 the Base LFB library in Section 6 are applied to achieve some typical 3836 router functions. The functions to demonstrate are: 3838 o IPv4 forwarding 3840 o ARP processing 3842 To achieve the functions, processing paths organized by the LFB 3843 classes with their interconnections should be established in FE. In 3844 general, CE controls and manages the processing paths by use of the 3845 ForCES protocol. 3847 Note that LFB class use cases shown in this section are only as 3848 examples to demonstrate how typical router functions are able to be 3849 implemented with the defined base LFB library. Users and 3850 implementers should not be limited by the example use cases. 3852 7.1. IPv4 Forwarding 3854 Figure 1 (Section 3.2.3) shows a normal IPv4 forwarding processing 3855 path by use of the base LFB classes. To make it in focus, LFB 3856 classes that are not close to IPv4 forwarding function are ignored in 3857 the figure. Moreover, inputs or outputs of some LFBs that are not 3858 related to IP forwarding are also ignored in the LFB figure. 3860 In the example case, network interfaces are limited to copper 3861 Ethernet ports. A number of EtherPHYCop LFBs are used to describe 3862 physical layer functions of the ports. An EtherMACIn LFB follows 3863 every EtherPHYCop LFB to describe the MAC layer processing. A 3864 PHYPortID metadatum is generated by EtherPHYCop LFB and will be used 3865 by all the following LFBs. In EtherMACIn LFB, a locality check of 3866 MAC addresses may be performed if CE asks to do so by configuring the 3867 LFB component. 3869 Ethernet packets out of the EtherMACIn LFB are sent to an 3870 EtherClassifier LFB to be decapsulated and classified into network 3871 layer types like IPv4, IPv6, ARP, etc. In the example case, every 3872 physical Ethernet interface is associated with one Classifier 3873 instance, whereas it is also practical that all physical interfaces 3874 are associated with only one Ethernet Classifier instance. 3875 EtherClassifier will use PHYPortID and Ethernet type of the input 3876 packet and VlanID, if exists in the input Ethernet packets, to decide 3877 the packet network layer type and its output port from this LFB, and 3878 also to assign a new logical port ID to the packet for later use. At 3879 the same time, the LFB also generate some new metadata for every 3880 packet like EtherType, SrcMAC, DstMAC, LogicPortID, etc for later 3881 LFBs to use. 3883 If a packet is classified as an IPv4 packet, it will be sent to an 3884 IPv4Validator LFB to validate the IPv4 packet. In the validator LFB, 3885 IPv4 packets will be classified into IPv4 unicast packets and 3886 multicast packets, as well as validating the IPv4 packets. 3888 IPv4 unicast packets will be sent to IPv4UcastLPM LFB, where LPM is 3889 made and a next hop ID is achieved. The packet with the next hop ID 3890 is further sent to an IPv4NextHop LFB, where further next hop 3891 information is found for this packet. The information includes where 3892 the packet is to go next and even the media encapsulation type for 3893 the port, etc. An L3PortID is used to identify a next hop output 3894 port, which is represented as a metadatum associated with the packet 3895 to be forwarded to via port. In the example case, the next hop 3896 output port is an Ethernet type. As a result, the packet and its L3 3897 port ID metadatum are sent to an EtherEncap LFB, where the packet is 3898 encapsulated as an Ethernet packet. A BasicMetadataDispatch LFB 3899 follows the EtherEncap LFB where packets will be dispatched to 3900 different output port according to the L3PortID metadatum sent to the 3901 LFB. As a result, IPv4 packets are forwarded out via various output 3902 ports. 3904 7.2. ARP processing 3906 Figure 2 shows the processing path for ARP protocol in the case that 3907 there is no specific ARP processing LFBs in FE. In such case, CE 3908 should implement the ARP processing function. As usual, to make it 3909 in focus, the figure ignores LFB classes that are not related to ARP 3910 processing. The figure also ignores some inputs or outputs of LFBs 3911 that are out of the scope of ARP processing. 3913 The example case still takes Ethernet ports as its network 3914 interfaces. 3916 +---+ +---+ 3917 | | ARP packets | | 3918 | |------------------------+--->| | To CE 3919 ...-->| | . | | | 3920 | | . | +---+ 3921 | | . | RedirectOut 3922 +---+ | 3923 Ether EtherEncap | IPv4 packets lack 3924 Classifier +---+ | address resolution information 3925 | | | 3926 Packets need | |--------->---+ 3927 ...--------->| | 3928 L2 Encapsulation| | 3929 +---+ | | +------+ 3930 | | +-->| |--+ +---+ |Ether | 3931 | | | +---+ | | |--------->|MACOut|-->... 3932 From CE| |--+ +-->| | . +------+ 3933 | |ARP Packets | | . 3934 | |from CE | | . +------+ 3935 | | | |--------> |Ether |-->... 3936 +---+ +---+ |MACOut| 3937 RedirectIn BasicMetadata +------+ 3938 Dispatch 3940 Figure 2: LFB use case for ARP 3942 As the figure shows, ARP protocol packets from network interfaces can 3943 be filtered out by EtherClassifier LFB. In the example case, we 3944 presume the FE does not provide ability for ARP processing and relies 3945 on CE to do the work. Hence, the classified ARP packets and some 3946 associated metadata are then sent to RedirectOut LFB so as to be 3947 transported to CE. CE can then process the received APR packets to 3948 get information to establish ARP tables. While it depends on 3949 individual implementations how this is implemented and is out of the 3950 scope of ForCES 3952 When CE deploys ARP function, it may need to generate ARP request or 3953 response packets and send them back to outer networks. To do so, the 3954 packets are redirected to FE through a RedirectIn LFB first. Then, 3955 just like to forward IPv4 packets, the ARP packets are also 3956 encapsulated to Ethernet format by an EtherEncap LFB, and then 3957 dispatched to different interfaces via a BasicMetadataDispatch LFB. 3958 The BasicMetadataDispatch LFB will dispatch the packets according to 3959 the L3PortID metadatum included in every ARP packet sent from CE. 3961 The EtherEncap LFB also receives packets that need Ethernet L2 3962 encapsulating. If the encapsulator finds that it can not fulfill 3963 encapsulating some packets because of lack of L2 Ethernet information 3964 for the packets, the LFB will output the packets from the 3965 ExceptionOut output of the LFB. By connecting this output to 3966 RedirectOut LFB, the packets can be redirected to CE for further ARP 3967 processing. See Section 5.1.4 for details. CE may then generate ARP 3968 requests based on the packets, and redirect ARP request messages to 3969 FE to send to networks, just as the procedure shown above. 3971 With these mechanisms and procedures, ARP function is expected to be 3972 implemented by CE with the help from FE. 3974 8. Contributors 3976 The authors would like to thank Jamal Hadi Salim, Ligang Dong, and 3977 Fenggen Jia who made major contributions to the development of this 3978 document. 3980 Jamal Hadi Salim 3981 Mojatatu Networks 3982 Ottawa, Ontario 3983 Canada 3984 Email: hadi@mojatatu.com 3986 Ligang Dong 3987 Zhejiang Gongshang University 3988 149 Jiaogong Road 3989 Hangzhou 310035 3990 P.R.China 3991 Phone: +86-571-28877751 3992 EMail: donglg@mail.zjgsu.edu.cn 3994 Fenggen Jia 3995 National Digital Switching Center(NDSC) 3996 Jianxue Road 3997 Zhengzhou 452000 3998 P.R.China 3999 EMail: jfg@mail.ndsc.com.cn 4001 9. Acknowledgements 4003 This document is based on earlier documents from Joel Halpern, Ligang 4004 Dong, Fenggen Jia and Weiming Wang. 4006 10. IANA Considerations 4008 IANA has created a registry of ForCES LFB Class Names and the 4009 corresponding ForCES LFB Class Identifiers, with the location of the 4010 definition of the ForCES LFB Class, in accordance with the rules to 4011 use the namespace. 4013 The LFB library in this document needs for unique class names and 4014 numeric class identifiers of all LFBs. Besides, this document also 4015 needs to define the following namespaces: 4017 o Metadata ID, defined in Section 4.3 and Section 4.4 4019 o Exception ID, defined in Section 4.4 4021 o Validate Error ID, defined in Section 4.4 4023 10.1. LFB Class Names and LFB Class Identifiers 4025 LFB classes defined by this document belongs to IETF defined LFBs by 4026 Standard Track RFCs. According to IANA, the identifier namespace for 4027 these LFB classes is from 3 to 65535. 4029 The assignment of LFB class names and LFB class identifiers is as in 4030 the following table. 4032 +-----------+---------------+------------------------+--------------+ 4033 | LFB Class | LFB Class Name| Description | Reference | 4034 | Identifier| | | | 4035 +-----------+---------------+------------------------+--------------+ 4036 | 3 | EtherPHYCop | Define an Ethernet port| RFC????(this| 4037 | | | abstracted at physical | document) | 4038 | | | layer | Section 5.1.1| 4039 | | | -------------- | | 4040 | 4 | EtherMACIn | Define an Ethernet | RFC???? | 4041 | | | input port at MAC data | Section 5.1.2| 4042 | | | link layer | | 4043 | | | -------------- | | 4044 | 5 |EtherClassifier| Define the process to | RFC???? | 4045 | | | decapsulate Ethernet | Section 5.1.3| 4046 | | | packets and classify | | 4047 | | | the packets | | 4048 | | | -------------- | | 4049 | 6 | EtherEncap | Define the process to | RFC???? | 4050 | | | encapsulate IP packets | Section 5.1.4| 4051 | | | to Ethernet packets | | 4052 | | | -------------- | | 4053 | 7 | EtherMACOut | Define an Ethernet | RFC ???? | 4054 | | | output port at MAC | Section 5.1.5| 4055 | | | data link layer | | 4056 | | | -------------- | | 4057 | 8 | IPv4Validator | Perform IPv4 packets | RFC ???? | 4058 | | | validation. | Section 5.2.1| 4059 | | | -------------- | | 4060 | 9 | IPv6Validator | Perform IPv6 packets | RFC ???? | 4061 | | | validation | Section 5.2.2| 4062 | | | -------------- | | 4063 | 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? | 4064 | | | Prefix Match Lookup | Section 5.3.1| 4065 | | | -------------- | | 4066 | 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC ???? | 4067 | | | Prefix Match Lookup | Section 5.3.3| 4068 | | | -------------- | | 4069 | 12 | IPv4NextHop | Define the process of | RFC ??? | 4070 | | | selecting Ipv4 next hop| Section 5.3.2| 4071 | | | action | | 4072 | | | -------------- | | 4073 | 13 | IPv6NextHop | Define the process of | RFC ??? | 4074 | | | selecting Ipv6 next hop| Section 5.3.4| 4075 | | | action | | 4076 | | | -------------- | | 4077 | 14 | RedirectIn | Define the process for | RFC ??? | 4078 | | | CE to inject data | Section 5.4.1| 4079 | | | packets into FE LFB | | 4080 | | | topology | | 4081 | | | -------------- | | 4082 | 15 | RedirectOut | Define the process for | RFC ??? | 4083 | | | LFBs in FE to deliver | Section 5.4.2| 4084 | | | data packets to CE | | 4085 | | | -------------- | | 4086 | 16 |BasicMetadata | Dispatch input packets | RFC ??? | 4087 | |Dispatch | to a group output | Section 5.5.1| 4088 | | | according to a metadata| | 4089 | | | -------------- | | 4090 | 17 |Generic | Define a preliminary | RFC ???? | 4091 | |Scheduler | generic scheduling | Section 5.5.2| 4092 | | | process | | 4093 +-----------+---------------+------------------------+--------------+ 4095 Table 1 4097 10.2. Metadata ID 4099 The Metadata ID namespace is 32 bits long. The following is the 4100 guideline for managing the namespace. 4102 Metadata ID 0x00000000-0x7FFFFFFF 4104 Metadata with IDs in this range are Specification Required 4105 [RFC5226]. A metadata ID using this range MUST be documented in 4106 an RFC or other permanent and readily available references. 4108 Values assigned by this specification: 4110 +--------------+-------------------------+--------------------------+ 4111 | Value | Name | Definition | 4112 +--------------+-------------------------+--------------------------+ 4113 | 0x00000001 | EtherPHYCop | See Section 4.4 | 4114 | 0x00000002 | SrcMAC | See Section 4.4 | 4115 | 0x00000003 | DstMAC | See Section 4.4 | 4116 | 0x00000004 | LogicalPortID | See Section 4.4 | 4117 | 0x00000005 | EtherType | See Section 4.4 | 4118 | 0x00000006 | VlanID | See Section 4.4 | 4119 | 0x00000007 | VlanPriority | See Section 4.4 | 4120 | 0x00000008 | NexthopIPv4Addr | See Section 4.4 | 4121 | 0x00000009 | NexthopIPv6Addr | See Section 4.4 | 4122 | 0x0000000A | HopSelector | See Section 4.4 | 4123 | 0x0000000B | ExceptionID | See Section 4.4 | 4124 | 0x0000000C | ValidateErrorID | See Section 4.4 | 4125 | 0x0000000D | L3PortID | See Section 4.4 | 4126 | 0x0000000E | RedirectIndex | See Section 4.4 | 4127 | 0x0000000F | MediaEncapInfoIndex | See Section 4.4 | 4128 +--------------+-------------------------+--------------------------+ 4130 Table 2 4132 Metadata ID 0x80000000-0xFFFFFFFFF 4134 Metadata IDs in this range are reserved for vendor private 4135 extensions and are the responsibility of individuals. 4137 10.3. Exception ID 4139 The Exception ID namespace is 32 bits long. The following is the 4140 guideline for managing the namespace. 4142 Exception ID 0x00000000-0x7FFFFFFF 4143 Exception IDs in this range are Specification Required [RFC5226]. 4144 An exception ID using this range MUST be documented in an RFC or 4145 other permanent and readily available references. 4147 Values assigned by this specification: 4149 +--------------+---------------------------------+------------------+ 4150 | Value | Name | Definition | 4151 +--------------+---------------------------------+------------------+ 4152 | 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 | 4153 | 0x00000001 | BroadCastPacket | See Section 4.4 | 4154 | 0x00000002 | BadTTL | See Section 4.4 | 4155 | 0x00000003 | IPv4HeaderLengthMismatch | See Section 4.4 | 4156 | 0x00000004 | LengthMismatch | See Section 4.4 | 4157 | 0x00000005 | RouterAlertOptions | See Section 4.4 | 4158 | 0x00000006 | RouteInTableNotFound | See Section 4.4 | 4159 | 0x00000007 | NextHopInvalid | See Section 4.4 | 4160 | 0x00000008 | FragRequired | See Section 4.4 | 4161 | 0x00000009 | LocalDelivery | See Section 4.4 | 4162 | 0x0000000A | GenerateICMP | See Section 4.4 | 4163 | 0x0000000B | PrefixIndexInvalid | See Section 4.4 | 4164 | 0x0000000C | IPv6HopLimitZero | See Section 4.4 | 4165 | 0x0000000D | IPv6NextHeaderHBH | See Section 4.4 | 4166 +--------------+---------------------------------+------------------+ 4168 Table 3 4170 Exception ID 0x80000000-0xFFFFFFFFF 4172 Exception IDs in this range are reserved for vendor private 4173 extensions and are the responsibility of individuals. 4175 10.4. Validate Error ID 4177 The Validate Error ID namespace is 32 bits long. The following is 4178 the guideline for managing the namespace. 4180 Validate Error ID 0x00000000-0x7FFFFFFF 4182 Validate Error IDs in this range are Specification Required 4183 [RFC5226]. A Validate Error ID using this range MUST be 4184 documented in an RFC or other permanent and readily available 4185 references. 4187 Values assigned by this specification: 4189 +--------------+---------------------------------+------------------+ 4190 | Value | Name | Definition | 4191 +--------------+---------------------------------+------------------+ 4192 | 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 | 4193 | 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 | 4194 | 0x00000002 | NotIPv4Packet | See Section 4.4 | 4195 | 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 | 4196 | 0x00000004 | InvalidIPv4Checksum | See Section 4.4 | 4197 | 0x00000005 | InvalidIPv4SrcAddrCase1 | See Section 4.4 | 4198 | 0x00000006 | InvalidIPv4SrcAddrCase2 | See Section 4.4 | 4199 | 0x00000007 | InvalidIPv4SrcAddrCase3 | See Section 4.4 | 4200 | 0x00000008 | InvalidIPv4SrcAddrCase4 | See Section 4.4 | 4201 | 0x00000009 | InvalidIPv6PakcetSize | See Section 4.4 | 4202 | 0x0000000A | NotIPv6Packet | See Section 4.4 | 4203 | 0x0000000B | InvalidIPv6SrcAddrCase1 | See Section 4.4 | 4204 | 0x0000000C | InvalidIPv6SrcAddrCase2 | See Section 4.4 | 4205 | 0x0000000D | InvalidIPv6DstAddrCase1 | See Section 4.4 | 4206 +--------------+---------------------------------+------------------+ 4207 Table 4 4209 Validate Error ID 0x80000000-0xFFFFFFFFF 4211 Validate Error IDs in this range are reserved for vendor private 4212 extensions and are the responsibility of individuals. 4214 11. Security Considerations 4216 The ForCES framework document [RFC3746] provides a comprehensive 4217 security analysis for the overall ForCES architecture. For example, 4218 the ForCES protocol entities must be authenticated per the ForCES 4219 requirements before they can access the information elements 4220 described in this document via ForCES. Access to the information 4221 contained in this document is accomplished via the ForCES 4222 protocol[RFC5810], which is defined in separate documents, and thus 4223 the security issues will be addressed there. 4225 12. References 4227 12.1. Normative References 4229 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 4230 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 4231 Control Element Separation (ForCES) Protocol 4232 Specification", RFC 5810, March 2010. 4234 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 4235 Element Separation (ForCES) Forwarding Element Model", 4236 RFC 5812, March 2010. 4238 12.2. Informative References 4240 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 4241 RFC 1812, June 1995. 4243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4244 Requirement Levels", BCP 14, RFC 2119, March 1997. 4246 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 4247 June 1999. 4249 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 4250 Text on Security Considerations", BCP 72, RFC 3552, 4251 July 2003. 4253 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 4254 of IP Control and Forwarding", RFC 3654, November 2003. 4256 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 4257 "Forwarding and Control Element Separation (ForCES) 4258 Framework", RFC 3746, April 2004. 4260 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4261 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 4262 May 2008. 4264 Authors' Addresses 4266 Weiming Wang 4267 Zhejiang Gongshang University 4268 18 Xuezheng Str., Xiasha University Town 4269 Hangzhou, 310018 4270 P.R.China 4272 Phone: +86-571-28877721 4273 Email: wmwang@zjgsu.edu.cn 4275 Evangelos Haleplidis 4276 University of Patras 4277 Patras, 4278 Greece 4280 Email: ehalep@ece.upatras.gr 4282 Kentaro Ogawa 4283 NTT Corporation 4284 Tokyo, 4285 Japan 4287 Email: ogawa.kentaro@lab.ntt.co.jp 4289 Chuanhuang Li 4290 Hangzhou BAUD Networks 4291 408 Wen-San Road 4292 Hangzhou, 310012 4293 P.R.China 4295 Phone: +86-571-28877751 4296 Email: chuanhuang_li@zjgsu.edu.cn 4298 Halpern Joel 4299 Ericsson 4300 P.O. Box 6049 4301 Leesburg, 20178 4302 VA 4304 Phone: +1 703 371 3043 4305 Email: joel.halpern@ericsson.com