idnits 2.17.1 draft-ietf-forces-lfb-lib-04.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 (June 2, 2011) is 4705 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 314, but not defined == Missing Reference: 'N' is mentioned on line 487, but not defined == Unused Reference: 'RFC1812' is defined on line 3667, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 3673, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 3676, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 3687, 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 (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Wang 3 Internet-Draft Zhejiang Gongshang University 4 Intended status: Standards Track E. Haleplidis 5 Expires: December 4, 2011 University of Patras 6 K. Ogawa 7 NTT Corporation 8 C. Li 9 Hangzhou BAUD Networks 10 J. Halpern 11 Ericsson 12 June 2, 2011 14 ForCES Logical Function Block (LFB) Library 15 draft-ietf-forces-lfb-lib-04 17 Abstract 19 This document defines basic classes of Logical Function Blocks (LFBs) 20 used in the Forwarding and Control Element Separation (ForCES). It 21 is defined according to ForCES FE model [RFC5812] and ForCES protocol 22 [RFC5810] specifications. These basic LFB classes are scoped to meet 23 requirements of typical router functions and considered as the basic 24 LFB library for ForCES. Descriptions of individual LFBs are 25 presented and detailed XML definitions are included in the library. 26 Several use cases of the defined LFB classes are also proposed. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 4, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Scope of the Library . . . . . . . . . . . . . . . . . . . 7 67 3.2. Overview of LFB Classes in the Library . . . . . . . . . . 9 68 3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . . 9 69 3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 9 70 3.2.3. Sample LFB Class Application . . . . . . . . . . . . . 11 71 3.3. Document Structure . . . . . . . . . . . . . . . . . . . . 12 72 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 4.1. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.2. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 4.3. MetaData . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 15 77 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 36 78 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 36 79 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 36 80 5.1.1.1. Data Handling . . . . . . . . . . . . . . . . . . 36 81 5.1.1.2. Components . . . . . . . . . . . . . . . . . . . . 37 82 5.1.1.3. Capabilities . . . . . . . . . . . . . . . . . . . 38 83 5.1.1.4. Events . . . . . . . . . . . . . . . . . . . . . . 38 84 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . . 38 85 5.1.2.1. Data Handling . . . . . . . . . . . . . . . . . . 38 86 5.1.2.2. Components . . . . . . . . . . . . . . . . . . . . 39 87 5.1.2.3. Capabilities . . . . . . . . . . . . . . . . . . . 40 88 5.1.2.4. Events . . . . . . . . . . . . . . . . . . . . . . 40 89 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 40 90 5.1.4. EtherEncapsulator . . . . . . . . . . . . . . . . . . 42 91 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 45 92 5.1.5.1. Data Handling . . . . . . . . . . . . . . . . . . 45 93 5.1.5.2. Components . . . . . . . . . . . . . . . . . . . . 45 94 5.1.5.3. Capabilities . . . . . . . . . . . . . . . . . . . 46 95 5.1.5.4. Events . . . . . . . . . . . . . . . . . . . . . . 46 96 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 46 97 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 46 98 5.2.1.1. Data Handling . . . . . . . . . . . . . . . . . . 46 99 5.2.1.2. Components . . . . . . . . . . . . . . . . . . . . 48 100 5.2.1.3. Capabilities . . . . . . . . . . . . . . . . . . . 48 101 5.2.1.4. Events . . . . . . . . . . . . . . . . . . . . . . 48 102 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 48 103 5.2.2.1. Data Handling . . . . . . . . . . . . . . . . . . 48 104 5.2.2.2. Components . . . . . . . . . . . . . . . . . . . . 50 105 5.2.2.3. Capabilities . . . . . . . . . . . . . . . . . . . 50 106 5.2.2.4. Events . . . . . . . . . . . . . . . . . . . . . . 50 107 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . . 50 108 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . . 51 109 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 52 110 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . . 54 111 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 54 112 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 54 113 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . . 54 114 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 55 115 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . . 55 116 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 56 117 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . . 56 118 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 58 119 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 80 120 7.1. IP Forwarding . . . . . . . . . . . . . . . . . . . . . . 80 121 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 81 122 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 82 123 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 124 11. Security Considerations . . . . . . . . . . . . . . . . . . . 84 125 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 126 12.1. Normative References . . . . . . . . . . . . . . . . . . . 85 127 12.2. Informative References . . . . . . . . . . . . . . . . . . 85 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86 130 1. Terminology and Conventions 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. Definitions 140 This document follows the terminology defined by the ForCES 141 Requirements in [RFC3654]and by the ForCES framework in [RFC3746]. 142 The definitions below are repeated for clarity. 144 Control Element (CE) - A logical entity that implements the ForCES 145 protocol and uses it to instruct one or more FEs on how to process 146 packets. CEs handle functionality such as the execution of 147 control and signaling protocols. 149 Forwarding Element (FE) - A logical entity that implements the 150 ForCES protocol. FEs use the underlying hardware to provide per- 151 packet processing and handling as directed/controlled by one or 152 more CEs via the ForCES protocol. 154 ForCES Network Element (NE) - An entity composed of one or more 155 CEs and one or more FEs. To entities outside an NE, the NE 156 represents a single point of management. Similarly, an NE usually 157 hides its internal organization from external entities. 159 LFB (Logical Function Block) - The basic building block that is 160 operated on by the ForCES protocol. The LFB is a well defined, 161 logically separable functional block that resides in an FE and is 162 controlled by the CE via ForCES protocol. The LFB may reside at 163 the FE's datapath and process packets or may be purely an FE 164 control or configuration entity that is operated on by the CE. 165 Note that the LFB is a functionally accurate abstraction of the 166 FE's processing capabilities, but not a hardware-accurate 167 representation of the FE implementation. 169 FE Topology - A representation of how the multiple FEs within a 170 single NE are interconnected. Sometimes this is called inter-FE 171 topology, to be distinguished from intra-FE topology (i.e., LFB 172 topology). 174 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. 175 An LFB Instance represents an LFB Class (or Type) existence. 176 There may be multiple instances of the same LFB Class (or Type) in 177 an FE. An LFB Class is represented by an LFB Class ID, and an LFB 178 Instance is represented by an LFB Instance ID. As a result, an 179 LFB Class ID associated with an LFB Instance ID uniquely specifies 180 an LFB existence. 182 LFB Metadata - Metadata is used to communicate per-packet state 183 from one LFB to another, but is not sent across the network. The 184 FE model defines how such metadata is identified, produced and 185 consumed by the LFBs. It defines the functionality but not how 186 metadata is encoded within an implementation. 188 LFB Component - Operational parameters of the LFBs that must be 189 visible to the CEs are conceptualized in the FE model as the LFB 190 components. The LFB components include, for example, flags, 191 single parameter arguments, complex arguments, and tables that the 192 CE can read and/or write via the ForCES protocol (see below). 194 LFB Topology - Representation of how the LFB instances are 195 logically interconnected and placed along the datapath within one 196 FE. Sometimes it is also called intra-FE topology, to be 197 distinguished from inter-FE topology. 199 ForCES Protocol - While there may be multiple protocols used 200 within the overall ForCES architecture, the term "ForCES protocol" 201 and "protocol" refer to the Fp reference points in the ForCES 202 Framework in [RFC3746]. This protocol does not apply to CE-to-CE 203 communication, FE-to-FE communication, or to communication between 204 FE and CE managers. Basically, the ForCES protocol works in a 205 master-slave mode in which FEs are slaves and CEs are masters. 206 This document defines the specifications for this ForCES protocol. 208 3. Introduction 210 RFC 3746 [RFC3746] specifies Forwarding and Control Element 211 Separation (ForCES) framework. In the framework, Control Elements 212 (CEs) configure and manage one or more separate Forwarding Elements 213 (FEs) within a Network Element (NE) by use of a ForCES protocol. RFC 214 5810 [RFC5810] specifies the ForCES protocol. RFC 5812 [RFC5812] 215 specifies the Forwarding Element (FE) model. In the model, resources 216 in FEs are described by classes of Logical Function Blocks (LFBs). 217 The FE model defines the structure and abstract semantics of LFBs, 218 and provides XML schema for the definitions of LFBs. 220 This document conforms to the specifications of the FE model 221 [RFC5812] and specifies detailed definitions of classes of LFBs, 222 including detailed XML definitions of LFBs. These LFBs form a base 223 LFB library for ForCES. LFBs in the base library are expected to be 224 combined to form an LFB topology for a typical router to implement IP 225 forwarding. It should be emphasized that an LFB is an abstraction of 226 functions rather than its implementation details. The purpose of the 227 LFB definitions is to represent functions so as to provide 228 interoperability between separate CEs and FEs. 230 More LFB classes with more functions may be developed in future time 231 and documented by IETF. Vendors may also develop proprietary LFB 232 classes as described in the FE model [RFC5812]. 234 3.1. Scope of the Library 236 It is intended that the LFB classes described in this document are 237 designed to provide the functions of a typical router. RFC 1812 238 specifies that a typical router is expected to provide functions to: 240 (1) Interface to packet networks and implement the functions required 241 by that network. These functions typically include: 243 o Encapsulating and decapsulating the IP datagrams with the 244 connected network framing (e.g., an Ethernet header and checksum), 246 o Sending and receiving IP datagrams up to the maximum size 247 supported by that network, this size is the network's Maximum 248 Transmission Unit or MTU, 250 o Translating the IP destination address into an appropriate 251 network-level address for the connected network (e.g., an Ethernet 252 hardware address), if needed, and 254 o Responding to network flow control and error indications, if any. 256 (2) Conform to specific Internet protocols including the Internet 257 Protocol (IPv4 and/or IPv6), Internet Control Message Protocol 258 (ICMP), and others as necessary. 260 (3) Receive and forwards Internet datagrams. Important issues in 261 this process are buffer management, congestion control, and fairness. 263 o Recognizes error conditions and generates ICMP error and 264 information messages as required. 266 o Drops datagrams whose time-to-live fields have reached zero. 268 o Fragments datagrams when necessary to fit into the MTU of the next 269 network. 271 (4) Choose a next-hop destination for each IP datagram, based on the 272 information in its routing database. 274 (5) Usually support an interior gateway protocol (IGP) to carry out 275 distributed routing and reachability algorithms with the other 276 routers in the same autonomous system. In addition, some routers 277 will need to support an exterior gateway protocol (EGP) to exchange 278 topological information with other autonomous systems. For all 279 routers, it is essential to provide ability to manage static routing 280 items. 282 (6) Provide network management and system support facilities, 283 including loading, debugging, status reporting, exception reporting 284 and control. 286 The classical IP router utilizing the ForCES framework constitutes a 287 CE running some controlling IGP and/or EGP function and FEs 288 implementing using Logical Function Blocks (LFBs) conforming to the 289 FE model[RFC5812] specifications. The CE, in conformance to the 290 ForCES protocol[RFC5810] and the FE model [RFC5812] specifications, 291 instructs the LFBs on the FE how to treat received/sent packets. 293 Packets in an IP router are received and transmitted on physical 294 media typically referred to as "ports". Different physical port 295 media will have different way for encapsulating outgoing frames and 296 decapsulating incoming frames. The different physical media will 297 also have different attributes that influence its behavior and how 298 frames get encapsulated or decapsulated. This document will only 299 deal with Ethernet physical media. Other future documents may deal 300 with other types of media. This document will also interchangeably 301 refer to a port to be an abstraction that constitutes a PHY and a MAC 302 as described by the LFBs like EtherPHYCop, EtherMACIn, and 303 EtherMACOut. 305 IP packets emanating from port LFBs are then processed by a 306 validation LFB before being further forwarded to the next LFB. After 307 the validation process the packet is passed to an LFB where IP 308 forwarding decision is made. In the IP Forwarding LFBs, a Longest 309 Prefix Match LFB is used to look up the destination information in a 310 packet and select a next hop index for sending the packet onward. A 311 next hop LFB uses the next hop index metadata to apply the proper 312 headers to the IP packets, and direct them to the proper egress. 313 Note that in the process of IP packets processing, in this document, 314 we are adhering to the weak-host model[RFC1122] since that is the 315 most usable model for a packet processing Network Element. 317 3.2. Overview of LFB Classes in the Library 319 It is critical to classify functional requirements into various 320 classes of LFBs and construct a typical but also flexible enough base 321 LFB library for various IP forwarding equipments. 323 3.2.1. LFB Design Choices 325 A few design principles were factored into choosing how the base LFBs 326 looked like. These are: 328 o if a function can be designed by either one LFB or two or more 329 LFBs with the same cost, the choice is to go with two or more LFBs 330 so as to provide more flexibility for implementers. 332 o when flexibility is not required, an LFB should take advantage of 333 its independence as much as possible and have minimal coupling 334 with other LFBs. The coupling may be from LFB attributes 335 definitions as well as physical implementations. 337 o unless there is a clear difference in functionality, similar 338 packet processing should not be represented as two or more 339 different LFBs. Or else, it may add extra burden on 340 implementation to achieve interoperability. 342 3.2.2. LFB Class Groupings 344 The document defines groups of LFBs for typical router function 345 requirements: 347 (1) A group of Ethernet processing LFBs are defined to abstract the 348 packet processing for Ethernet as the port media type. As the most 349 popular media type with rich processing features, Ethernet media 350 processing LFBs was a natural choice. Definitions for processing of 351 other port media types like POS or ATM may be incorporated in the 352 library in future version of the document or in a future separate 353 document. 355 The following LFBs are defined for Ethernet processing: 357 EtherPHYCop (section 5.1.1) 359 EtherMACIn (section 5.1.2) 361 EtherClassifier (section 5.1.3) 363 EtherEncapsulator (section 5.1.4) 365 EtherMACOut (section 5.1.5) 367 (2) A group of LFBs are defined for IP packet validation process. 369 The following LFBs are defined for IP Validation processing: 371 IPv4Validator (section 5.2.1) 373 IPv6Validator (section 5.2.2) 375 (3) A group of LFBs are defined to abstract IP forwarding process. 377 The following LFBs are defined for IP Forwarding processing: 379 IPv4UcastLPM (section 5.3.1) 381 IPv4NextHop (section 5.3.2) 383 IPv6UcastLPM (section 5.3.4) 385 IPv6NextHop (section 5.3.4) 387 (4) A group of LFBs are defined to abstract the process for redirect 388 operation, i.e., data packet transmission between CE and FEs. 390 The following LFBs are defined for redirect processing: 392 RedirectIn (section 5.5.1) 394 RedirectOut (section 5.5.2) 396 (5) A group of LFBs are defined for abstracting some general purpose 397 packet processing. These processing processes are usually general to 398 many processing locations in an FE LFB topology. 400 The following LFBs are defined for redirect processing: 402 BasicMetadataDispatch (section 5.6.1) 404 GenericScheduler (section 5.6.2) 406 3.2.3. Sample LFB Class Application 408 Although section 7 will present use cases for LFBs defined in this 409 document, this section shows a sample LFB class application in 410 advance so that readers can get a quick overlook of the LFB classes 412 Figure 1 shows the typical LFB processing path for an IPv4 unicast 413 forwarding case with Ethernet media interfaces. To focus on the IP 414 forwarding function, some inputs or outputs of LFBs in the figure 415 that are not related to the function are missed. Section 7.1 will 416 describe the LFB topology in more details. 418 +-----+ +------+ 419 | | | | 420 | |<---------------|Ether |<----------------------------+ 421 | | |MACOut| | 422 | | | | | 423 |Ether| +------+ | 424 |PHY | | 425 |Cop | +---+ | 426 |#1 | +-----+ | |----->IPv6 Packets | 427 | | | | | | +----+ | 428 | | |Ether| | | | | | 429 | |->|MACIn|-->| |IPv4| | | 430 +-----+ | | | |-+->| | +---+ | 431 +-----+ +--+ | | |unicast +-----+ | | | 432 Ether | | |------->| | | | | 433 . Classifier| | |packet |IPv4 | | | | 434 . | | | |Ucast|->| |--+ | 435 . | | | |LPM | | | | | 436 +---+ | +----+ +-----+ | | | | 437 +-----+ | | | IPv4 +---+ | | 438 | | | | | Validator IPv4 | | 439 +-----+ |Ether| | |-+ NextHop | | 440 | |->|MACIn|-->| |IPv4 | | 441 | | | | | |----->IPv6 Packets | | 442 |Ether| +-----+ +---+ +----+ | | 443 |PHY | Ether | | | | 444 |Cop | Classifier | | +-------+ | | 445 |#n | | | | | | | 446 | | +------+ | |<--| Ether |<-+ | 447 | | | |<------| | | Encap | | 448 | |<---------------|Ether | ...| | +-------+ | 449 | | |MACOut| +---| | | 450 | | | | | +----+ | 451 +-----+ +------+ | BasicMetadataDispatch | 452 +-------------------------+ 454 Figure 1: AIPv4 Forwarding Case 456 3.3. Document Structure 458 Base type definitions, including data types, packet frame types, and 459 etadata types are presented in advance for definitions of various LFB 460 classes. Section 4 (Base Types Section) provide a description on the 461 base types used by this LFB library. In order for an extensive use 462 of these base types for other LFB class definitions, the base type 463 definitions are provided by an xml file in a way as a library which 464 is separate from the LFB definition library. 466 Within every group of LFB classes, a set of LFBs are defined for 467 individual function purposes. Section 5 (LFB Class Descriptions 468 Section) makes text descriptions on the individual LFBs. Note that 469 for a complete definition of an LFB, a text description as well as a 470 XML definition is required. 472 LFB classes are finally defined by XML with specifications and schema 473 defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB 474 Definitions Section) provide the complete XML definitions of the base 475 LFB classes library.. 477 Section 7 provides several use cases on how some typical router 478 functions can be implemented using the base LFB library defined in 479 this document. 481 4. Base Types 483 TThe FE model [RFC5812] has specified the following data types as 484 predefined (built-in) atomic data-types: 486 char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], 487 string, byte[N], boolean, octetstring[N], float16, float32, float64. 489 Based on these atomic data types and with the use of type definition 490 elements in the FE model XML schema, new data types, packet frame 491 types, and metadata types can further be defined. 493 To define a base LFB library for typical router functions, a base 494 data types, frame types, and metadata types MUST be defined. This 495 section provides a description of these types and detailed XML 496 definitions for the base types. 498 In order for extensive use of the base type definitions for LFB 499 definitions other than this base LFB library, the base type 500 definitions are provided with a separate xml library file labeled 501 with "BaseTypeLibrary". Users can refer to this library by the 502 statement: 504 506 4.1. Data 508 The following data types are currently defined and put in the base 509 type library: 511 (TBD) 513 4.2. Frame 515 According to FE model [RFC5812], frame types are used in LFB 516 definitions to define the types of frames the LFB expects at its 517 input port(s) and emits at its output port(s). The 518 element in the FE model is used to define a new frame type. 520 The following frame types are currently defined and put in the base 521 type library as base frame types for the LFB library: 523 (TBD) 525 4.3. MetaData 527 LFB Metadata is used to communicate per-packet state from one LFB to 528 another. The element in the FE model is used to define 529 a new metadata type. 531 The following metadata types are currently defined and put in the 532 base type library as base metadata types for the LFB library 533 definitions: 535 (TBD) 537 4.4. XML for Base Type Library 539 540 543 544 545 EthernetAll 546 An kinds of Ethernet frame 547 548 549 EthernetII 550 An Ethernet II frame 551 552 553 ARP 554 an arp packet 555 556 557 IPv4 558 An IPv4 packet 559 560 561 IPv6 562 An IPv6 packet 563 564 565 IPv4Unicast 566 An IPv4 unicast packet 567 568 569 IPv4Multicast 570 An IPv4 multicast packet 571 572 573 IPv6Unicast 574 An IPv6 unicast packet 575 576 577 IPv6Multicast 578 An IPv6 multicast packet 579 580 581 Arbitrary 582 Any kinds of frames 583 584 585 586 587 IPv4Addr 588 IPv4 address 589 byte[4] 590 591 592 IPv6Addr 593 IPv6 address 594 byte[16] 595 596 597 IEEEMAC 598 IEEE mac. 599 byte[6] 600 601 602 LANSpeedType 603 604 Network speed values 605 606 uint32 607 608 609 LAN_SPEED_10M 610 10M Ethernet 611 612 613 LAN_SPEED_100M 614 100M Ethernet 615 616 617 LAN_SPEED_1G 618 1000M Ethernet 619 620 621 LAN_SPEED_10G 622 10G Ethernet 623 624 625 LAN_SPEED_AUTO 626 LAN speed auto 627 628 629 630 631 632 DuplexType 633 634 Duplex types 635 636 uint32 637 638 639 Auto 640 Auto negotitation. 641 642 643 Half-duplex 644 port negotitation half duplex 645 646 647 Full-duplex 648 port negotitation full duplex 649 650 651 652 653 654 655 PortStatusValues 656 The possible values of status. Used for both 657 administrative and operation status. 658 659 uchar 660 661 662 Disabled 663 the port is operatively disabled. 664 665 666 UP 667 the port is up. 669 670 671 Down 672 The port is down. 673 674 675 676 677 678 MACInStatsType 679 The content of statistic for EtherMACIn. 680 681 682 NumPacketsReceived 683 The number of packets received. 684 uint64 685 686 687 NumPacketsDropped 688 The number of packets dropped. 689 uint64 690 691 692 693 694 MACOutStatsType 695 The content of statistic for EtherMACOut. 696 697 698 NumPacketsTransmitted 699 The number of packets transmitted. 700 uint64 701 702 703 NumPacketsDropped 704 The number of packets dropped. 705 uint64 706 707 708 709 710 EtherDispatchEntryType 711 the type of EtherDispatch table entry. 712 713 714 LogicalPortID 715 Logical port ID. 716 uint32 718 719 720 EtherType 721 The EtherType value in the Ether head. 722 723 uint32 724 725 726 OutputIndex 727 Group output port index. 728 uint32 729 730 731 732 733 EtherDispatchTableType 734 the type of EtherDispatch table. 735 736 EtherDispatchEntryType 737 738 739 740 VlanInputTableEntryType 741 Vlan input table entry type. 742 743 744 IncomingPortID 745 The incoming port ID. 746 uint32 747 748 749 VlanID 750 Vlan ID. 751 uint32 752 753 754 LogicalPortID 755 logical port ID. 756 uint32 757 758 759 760 761 VlanInputTableType 762 Vlan input table type. 763 764 VlanInputTableEntryType 765 767 768 769 EtherClassifyStatsType 770 Ether classify statistic information. 771 772 773 EtherType 774 The EtherType value 775 uint32 776 777 778 PacketsNum 779 Packets number 780 uint64 781 782 783 784 785 EtherClassifyStatsTableType 786 Ether classify statistic information 787 table type. 788 789 EtherClassifyStatsType 790 791 792 793 IPv4ValidatorStatisticsType 794 Statistics type in IPv4validator. 795 796 797 badHeaderPkts 798 Number of bad header packets. 799 uint64 800 801 802 badTotalLengthPkts 803 Number of bad total length packets. 804 uint64 805 806 807 badTTLPkts 808 Number of bad TTL packets. 809 uint64 810 811 812 badChecksumPkts 813 Number of bad checksum packets. 814 uint64 816 817 818 819 820 IPv6ValidatorStatisticsType 821 Statistics type in IPv6validator. 822 823 824 badHeaderPkts 825 Number of bad header packets. 826 uint64 827 828 829 badTotalLengthPkts 830 Number of bad total length packets. 831 uint64 832 833 834 badHopLimitPkts 835 Number of bad Hop limit packets. 836 uint64 837 838 839 840 841 IPv4PrefixInfoType 842 IPv4 Prefix information,entry type for 843 IPv4 prefix table. 844 845 846 IPv4Address 847 An IPv4 Address 848 IPv4Addr 849 850 851 Prefixlen 852 The prefix length 853 854 uchar 855 856 857 858 859 860 861 HopSelector 862 HopSelector is the nexthop ID which points to 863 the nexthop table 864 uint32 865 866 867 ECMPFlag 868 An ECMP Flag for this route 869 870 boolean 871 872 873 False 874 This route does not have multiple 875 nexthops. 876 877 878 True 879 This route has multiple nexthops. 880 881 882 883 884 885 886 DefaultRouteFlag 887 A Default Route Flag for supporting loose RPF. 888 889 890 boolean 891 892 893 False 894 This is not a default route. 895 896 897 898 True 899 This route is a default route. for 900 supporting the loose RPF. 901 902 903 904 905 906 907 908 IPv4PrefixTableType 909 IPv4 prefix table type. 910 911 IPv4PrefixInfoType 913 914 915 916 IPv4UcastLPMStatsType 917 Statistics type in IPv4Unicast. 918 919 920 InRcvdPkts 921 The total number of input packets 922 received 923 uint64 924 925 926 FwdPkts 927 IPv4 packets forwarded by this LFB 928 uint64 929 930 931 NoRoutePkts 932 The number of IP datagrams discarded because 933 no route could be found. 934 uint64 935 936 937 938 939 IPv6PrefixInfoType 940 IPv6 Prefix information,entry type for 941 IPv6 prefix table 942 943 944 IPv6Address 945 An IPv6 Address 946 IPv6Addr 947 948 949 Prefixlen 950 The prefix length 951 952 uchar 953 954 955 956 957 958 959 HopSelector 960 HopSelector is the nexthop ID which points 961 to the nexthop table 962 uint32 963 964 965 ECMPFlag 966 An ECMP Flag for this route 967 968 boolean 969 970 971 False 972 This route does not have multiple 973 nexthops. 974 975 976 True 977 This route has multiple nexthops. 978 979 980 981 982 983 984 DefaultRouteFlag 985 A Default Route Flag. 986 987 boolean 988 989 990 False 991 This is not a default route. 992 993 994 995 True 996 This route is a default route. 997 998 999 1000 1001 1002 1003 1004 1005 IPv6PrefixTableType 1006 IPv6 prefix table type. 1007 1008 IPv6PrefixInfoType 1010 1011 1012 1013 IPv6UcastLPMStatsType 1014 Statistics type in IPv6Unicast. 1015 1016 1017 InRcvdPkts 1018 The total number of input packets 1019 received 1020 uint64 1021 1022 1023 FwdPkts 1024 IPv6 packets forwarded by this LFB 1025 uint64 1026 1027 1028 NoRoutePkts 1029 The number of IP datagrams discarded because 1030 no route could be found. 1031 uint64 1032 1033 1034 1035 1036 IPv4NextHopInfoType 1037 IPv4 next hop information. Entry type for the 1038 IPv4 next hop table. 1039 1040 1041 L3PortID 1042 The ID of the Logical/physical Output Port 1043 that we pass onto the neighboring LFB instance. This 1044 ID indicates what port to the neighbor is as defined 1045 by L3. 1046 uint32 1047 1048 1049 MTU 1050 Maximum Transmission Unit for out going port. 1051 It is for desciding whether the packet need 1052 fragmentation 1053 uint32 1054 1055 1056 NextHopIPAddr 1057 Next Hop IPv4 Address 1058 IPv4Addr 1059 1060 1061 MediaEncapInfoIndex 1062 The index we pass onto the neighboring LFB 1063 instance. This index is used to lookup a table 1064 (typically media encapsulatation related) further 1065 downstream. 1066 uint32 1067 1068 1069 LFBOutputSelectIndex 1070 LFB Group output port index to select 1071 downstream LFB port. Some possibilities of downstream 1072 LFB instances are: 1073 a) EtherEncapsulator 1074 b) Other type of media LFB 1075 c) A metadata Dispatcher 1076 d) A redirect LFB 1077 e) etc 1078 Note: LFBOutputSelectIndex is the FromPortIndex for 1079 the port group "successout" in the table LFBTopology 1080 (of FEObject LFB) as defined for the NH LFB. 1081 1082 uint32 1083 1084 1085 1086 1087 IPv4NextHopTableType 1088 IPv4 next hop table type 1089 1090 IPv4NextHopInfoType 1091 1092 1093 1094 IPv6NextHopInfoType 1095 IPv6 next hop information. Entry type for the 1096 IPv6NextHopTable. 1097 1098 1099 L3PortID 1100 The ID of the Logical/physical Output Port 1101 that we pass onto the neighboring LFB instance. This 1102 ID indicates what port to the neighbor is as defined 1103 by L3. 1104 uint32 1105 1106 1107 MTU 1108 Maximum Transmission Unit for out going port. 1109 It is for desciding whether the packet need 1110 fragmentation. 1111 uint32 1112 1113 1114 NextHopIPAddr 1115 Next Hop IPv6 Address 1116 IPv6Addr 1117 1118 1119 MediaEncapInfoIndex 1120 The index we pass onto the neighboring LFB 1121 instance. This index is used to lookup a table 1122 (typically media encapsulatation related) further 1123 downstream. 1124 uint32 1125 1126 1127 LFBOutputSelectIndex 1128 LFB Group output port index to select 1129 downstream LFB port. Some possibilities of downstream 1130 LFB instances are: 1131 a) EtherEncapsulator 1132 b) Other type of media LFB 1133 c) A metadata Dispatcher 1134 d) A redirect LFB 1135 e) etc 1136 Note: LFBOutputSelectIndex is the FromPortIndex for 1137 the port group "successout" in the table LFBTopology 1138 (of FEObject LFB) as defined for the NH LFB. 1139 1140 uint32 1141 1142 1143 1144 1145 IPv6NextHopTableType 1146 IPv6 next hop table type 1147 1148 IPv6NextHopInfoType 1149 1150 1151 1152 EncapTableEntryType 1153 Ethernet encapsulation table entry type. 1154 1155 1156 DstMac 1157 Ethernet Mac of the Neighbor 1158 IEEEMAC 1159 1160 1161 SrcMac 1162 Source MAC used in encapsulation 1163 IEEEMAC 1164 1165 1166 VlanID 1167 VLAN ID. 1168 uint32 1169 1170 1171 L2PortID 1172 Output logical L2 port ID. 1173 uint32 1174 1175 1176 1177 1178 EncapTableType 1179 Ethernet encapsulation table type 1180 1181 EncapTableEntryType 1182 1183 1184 1185 MetadataDispatchType 1186 The entry type for Metadata dispatch table. 1187 1188 1189 1190 MetadataID 1191 metadata ID 1192 uint32 1193 1194 1195 MetadataValue 1196 metadata value. 1197 uint32 1198 1199 1200 OutputIndex 1201 group output port index. 1202 uint32 1203 1204 1205 1206 1207 MetadataDispatchTableType 1208 Metadata dispatch table type. 1209 1210 MetadataDispatchType 1211 1212 1213 1214 SchdDisciplineType 1215 scheduling discipline type. 1216 1217 uint32 1218 1219 1220 FIFO 1221 First In First Out scheduler. 1222 1223 1224 RR 1225 Round Robin. 1226 1227 1228 1229 1230 1231 QueueDepthType 1232 the entry type for queue depth 1233 table. 1234 1235 1236 QueueID 1237 Queue ID 1238 uint32 1239 1240 1241 QueueDepthInPackets 1242 the Queue Depth when the depth units 1243 are packets. 1244 uint32 1245 1246 1247 QueueDepthInBytes 1248 the Queue Depth when the depth units 1249 are bytes. 1250 uint32 1251 1252 1253 1254 1255 QueueDepthTableType 1256 the Depth of Queue table type. 1257 1258 QueueDepthType 1259 1260 1261 1262 1263 1264 PHYPortID 1265 The physical port ID that a packet has entered. 1266 1267 1 1268 uint32 1269 1270 1271 SrcMAC 1272 Source MAC Address 1273 2 1274 IEEEMAC 1275 1276 1277 DstMAC 1278 Destination MAC Address 1279 3 1280 IEEEMAC 1281 1282 1283 LogicalPortID 1284 ID of logical port. 1285 4 1286 uint32 1287 1288 1289 EtherType 1290 The value of EtherType. 1291 5 1292 uint32 1293 1294 1295 VlanID 1296 Vlan ID. 1297 6 1298 uint32 1299 1300 1301 VlanPriority 1302 The priority of Vlan. 1303 7 1304 uint32 1305 1306 1307 NexthopIPv4Addr 1308 Nexthop IP address. 1309 8 1310 IPv4Addr 1311 1312 1313 NexthopIPv6Addr 1314 Nexthop IP address. 1315 9 1316 IPv6Addr 1317 1318 1319 HopSelector 1320 HopSelector is the nexthop ID which points to the 1321 nexthop table 1322 10 1323 uint32 1324 1325 1326 ExceptionID 1327 Exception Types 1328 11 1329 1330 uint32 1331 1332 1333 Other 1334 Any other exception. 1335 1336 1337 BroadCastPacket 1338 Packet with destination address equal to 1339 255.255.255.255 1340 1341 1342 BadTTL 1343 The packet can't be forwarded as the TTL 1344 has expired. 1345 1346 1347 IPv4HeaderLengthMismatch 1348 IPv4 Packet's header length is less 1349 than 5. 1350 1351 1352 LengthMismatch 1353 The packet length reported by link layer 1354 is less than the total length field. 1355 1356 1357 RouterAlertOptions 1358 Packet IP head include Router Alert 1359 options. 1360 1361 1362 RouteInTableNotFound 1363 There is no route in the route table 1364 corresponding to the packet destination address 1365 1366 1367 1368 NextHopInvalid 1369 The NexthopID is invalid 1370 1371 1372 FragRequired 1373 The MTU for outgoing interface is less 1374 than the packet size. 1375 1376 1377 LocalDelivery 1378 The packet is for a local interface. 1379 1380 1381 1382 GenerateICMP 1383 ICMP packet needs to be generated. 1384 1385 1386 1387 PrefixIndexInvalid 1388 The prefixIndex is wrong. 1389 1390 1391 IPv6HopLimitZero 1392 Packet with Hop Limit zero 1393 1394 1395 IPv6NextHeaderHBH 1396 Packet with next header set to Hop-by-Hop 1397 1398 1399 1400 1401 1402 1403 ValidateErrorID 1404 Validate Error Types 1405 12 1406 1407 uint32 1408 1409 1410 Other 1411 Any other validation error. 1412 1413 1414 InvalidIPv4PacketSize 1415 Packet size reported is less than 20 1416 bytes. 1417 1418 1419 NotIPv4Packet 1420 Packet is not IP version 4. 1421 1422 1423 InvalidIPv4HeaderLengthSize 1424 Packet's header length is less than 5. 1425 1426 1427 1428 InvalidIPv4Checksum 1429 Packet with invalid checksum. 1430 1431 1432 InvalidIPv4SrcAddr1 1433 Packet with source address equal to 1434 255.255.255.255. 1435 1436 1437 InvalidIPv4SrcAddr2 1438 Packet with source address 0. 1439 1440 1441 InvalidIPv4SrcAddr3 1442 Packet with source address of form 1443 127.any. 1444 1445 1446 InvalidIPv4SrcAddr4 1447 Packet with source address in Class E 1448 domain. 1449 1450 1451 InvalidIPv6PakcetSize 1452 Packet size reported is less than 40 1453 bytes. 1454 1455 1456 NotIPv6Packet 1457 Packet is not IP version 6. 1458 1459 1460 InvalidIPv6SrcAddr1 1461 Packet with multicast source address (the 1462 MSB of the source address is 0xFF). 1463 1464 1465 InvalidIPv6SrcAddr2 1466 Packet with source address set to 1467 loopback(::1). 1468 1469 1470 InvalidIPv6DstAddr1 1471 Packet with destination set to 0 or ::1. 1472 1473 1474 1475 1476 1477 1478 L3PortID 1479 ID of L3 port. 1480 13 1481 uint32 1482 1483 1484 RedirectIndex 1485 Redirect Output port index. 1486 14 1487 uint32 1488 1489 1490 MediaEncapInfoIndex 1491 The index for media encap table in Media encap LFB. 1492 1493 15 1494 uint32 1495 1496 1497 1499 5. LFB Class Description 1501 According to ForCES specifications, LFB (Logical Function Block) is a 1502 well defined, logically separable functional block that resides in an 1503 FE, and is a functionally accurate abstraction of the FE's processing 1504 capabilities. An LFB Class (or type) is a template that represents a 1505 fine-grained, logically separable aspect of FE processing. Most LFBs 1506 are related to packet processing in the data path. LFB classes are 1507 the basic building blocks of the FE model. Note that RFC 5810 has 1508 already defined an 'FE Protocol LFB' which is as a logical entity in 1509 each FE to control the ForCES protocol. RFC 5812 has already defined 1510 an 'FE Object LFB'. Information like the FE Name, FE ID, FE State, 1511 LFB Topology in the FE are represented in this LFB. 1513 As specified in Section 3.1, this document focuses the base LFB 1514 library for implementing typical router functions, especially for IP 1515 forwarding functions. As a result, LFB classes in the library are 1516 all base LFBs to implement router forwarding. 1518 5.1. Ethernet Processing LFBs 1520 As the most popular physical and data link layer protocols, Ethernets 1521 are widely deployed. It becomes a basic requirement for a router to 1522 be able to process various Ethernet data packets. 1524 Note that there exist different versions of Ethernet protocols, like 1525 Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP. 1526 There also exist varieties of LAN techniques based on Ethernet, like 1527 various VLANs, MACinMAC, etc. Ethernet processing LFBs defined here 1528 are intended to be able to cope with all these variations of Ethernet 1529 technology. 1531 There are also various types of Ethernet physical interface media. 1532 Among them, copper and fiber media may be the most popular ones. As 1533 a base LFB definition and a start work, the document only defines an 1534 Ethernet physical LFB with copper media. For other media interfaces, 1535 specific LFBs may be defined in the future versions of the library. 1537 5.1.1. EtherPHYCop 1539 EtherPHYCop LFB abstracts an Ethernet interface physical layer with 1540 media limited to copper. 1542 5.1.1.1. Data Handling 1544 This LFB is the interface to the Ethernet physical media. The LFB 1545 handles ethernet frames coming in from or going out of the FE. 1546 Ethernet frames sent and received cover all packets encapsulated with 1547 different versions of Ethernet protocols, like Ethernet V2, 802.3 1548 RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets 1549 encapsulated with varieties of LAN techniques based on Ethernet, like 1550 various VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll 1551 frame type has been introduced. 1553 Ethernet frames are received from the physical media port and passed 1554 downstream to LFBs such as EtherMACIn via a singleton output known as 1555 "EtherPHYOut". A 'PHYPortID' metadatum, to indicate which physical 1556 port the frame came into from the external world, is passed along 1557 with the frame. 1559 Ethernet packets are received by this LFB from upstream LFBs such 1560 EtherMacOut via the singleton input known as "EtherPHYIn" before 1561 being sent out onto the external world. 1563 5.1.1.2. Components 1565 The AdminStatus component is defined for CE to administratively 1566 manage the status of the LFB. The CE may adminstratively startup or 1567 shutdown the LFB by changing the value of AdminStatus. The default 1568 value is set to 'Down'. 1570 An OperStatus component captures the physical port operational 1571 status. A PHYPortStatusChanged event is defined so the LFB can 1572 report to the CE whenever there is an operational status change of 1573 the physical port. 1575 The PHYPortID component is a unique identification for a physical 1576 port. It is defined as 'read-only' by CE. Its value is enumerated 1577 by FE. The component will be used to produce a 'PHYPortID' metadatum 1578 at the LFB output and to associate it to every Ethernet packet this 1579 LFB receives. The metadatum will be handed to downstream LFBs for 1580 them to use the PHYPortID. 1582 A group of components are defined for link speed management. The 1583 AdminLinkSpeed is for CE to configure link speed for the port and the 1584 OperLinkSpeed is for CE to query the actual link speed in operation. 1585 The default value for the AdminLinkSpeed is set to auto-negotiation 1586 mode. 1588 A group of components are defined for duplex mode management. The 1589 AdminDuplexMode is for CE to configure proper duplex mode for the 1590 port and the OperDuplexMode is for CE to query the actual duplex mode 1591 in operation. The default value for the AdminDuplexMode is set to 1592 auto-negotiation mode. 1594 A CarrierStatus component captures the status of the carrier and 1595 specifies whether the port is linked with an operational connector. 1596 The default value for the CarrierStatus is 'false'. 1598 5.1.1.3. Capabilities 1600 The capability information for this LFB includes the link speeds that 1601 are supported by the FE (SupportedLinkSpeed) as well as the supported 1602 duplex modes (SupportedDuplexMode). 1604 5.1.1.4. Events 1606 This LFB is defined to be able to generate several events in which 1607 the CE may be interested. There is an event for changes in the 1608 status of the physical port (PhyPortStatusChanged). Such an event 1609 will notify that the physical port status has been changed and the 1610 report will include the new status of the physical port. 1612 Another event captures changes in the operational link speed 1613 (LinkSpeedChanged). Such an event will notify the CE that the 1614 operational speed has been changed and the report will include the 1615 new negotiated operational speed. 1617 A final event captures changes in the duplex mode 1618 (DuplexModeChanged). Such an event will notify the CE that the 1619 duplex mode has been changed and the report will include the new 1620 negotiated duplex mode. 1622 5.1.2. EtherMACIn 1624 EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. It 1625 specifically describes Ethernet processing functions like MAC address 1626 locality check, deciding if the Ethernet packets should be bridged, 1627 provide Ethernet layer flow control, etc. 1629 5.1.2.1. Data Handling 1631 The LFB is expected to receive all types of Ethernet packets, via a 1632 singleton input known as "EtherMACIn", which are usually output from 1633 some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside 1634 with a metadatum indicating the physical port ID that the packet 1635 comes. 1637 The LFB is defined with two separate singleton outputs. All Output 1638 packets are in Ethernet format, as received from the physical layer 1639 LFB and cover all types of Ethernet packets. 1641 The first singleton output is known as "NormalPathOut". It usually 1642 outputs Ethernet packets to some LFB like an EtherClassifier LFB for 1643 further L3 forwarding process alongside with a PHYPortID metadata 1644 indicating which physical port the packet came from. 1646 The second singleton output is known as "L2BridgingPathOut". 1647 Although the LFB library this document defines is basically to meet 1648 typical router functions, it will attempt to be forward compatible 1649 with future router functions. The "L2BridgingPathOut" is defined to 1650 meet the requirement that L2 bridging functions may be optionally 1651 supported simultaneously with L3 processing and some L2 bridging LFBs 1652 that may be defined in the future. If the FE supports L2 bridging, 1653 the CE can enable or disable it by means of a "L2BridgingPathEnable" 1654 component in the FE. If it is enabled, by also instantiating some L2 1655 bridging LFB instances following the L2BridgingPathOut, FEs are 1656 expected to fulfill L2 bridging functions. L2BridgingPathOut will 1657 output packets exactly the same as that in the NormalPathOut output. 1659 This LFB can be set to work in a Promiscuous Mode, allowing all 1660 packets to pass through the LFB without being dropped. Otherwise, a 1661 locality check will be performed based on the local MAC addresses. 1662 All packets that do not pass through the locality check will be 1663 dropped. 1665 This LFB can perform Ethernet layer flow control. This is usually 1666 implemented cooperatively by the EtherMACIn LFB and the EtherMACOut 1667 LFB. The flow control is further distinguished by Tx flow control 1668 and Rx flow control, separately for sending process and receiving 1669 process flow controls. 1671 5.1.2.2. Components 1673 The AdminStatus component is defined for CE to administratively 1674 manage the status of the LFB. The CE may administratively startup or 1675 shutdown the LFB by changing the value of AdminStatus. The default 1676 value is set to 'Down'. 1678 The LocalMACAddresses component specifies the local MAC addresses 1679 based on which locality checks will be made. This component is an 1680 array of MAC addresses, and of 'read-write' access permission. 1682 An L2BridgingPathEnable component captures whether the LFB is set to 1683 work as a L2 bridge. An FE that does not support bridging will 1684 internally set this flag to false, and additionally set the flag 1685 property as read-only. The default value for is 'false'. 1687 The PromiscuousMode component specifies whether the LFB is set to 1688 work as in a promiscuous mode. The default value for is 'false'. 1690 The TxFlowControl component defines whether the LFB is performing 1691 flow control on sending packets. The default value for is 'false' 1693 The RxFlowControl component defines whether the LFB is performing 1694 flow contron on receiving packets. The default value for is 'false'. 1696 A struct component, MACInStats, defines a set of statistics for this 1697 LFB, including the number of received packets and the number of 1698 dropped packets. 1700 5.1.2.3. Capabilities 1702 This LFB does not have a list of capabilities. 1704 5.1.2.4. Events 1706 This LFB does not have any events specified. 1708 5.1.3. EtherClassifier 1710 EtherClassifier LFB abstracts the process to decapsulate Ethernet 1711 packets and classify the data packets into various network layer data 1712 packets according to information included in the Ethernet packets 1713 headers. 1715 Input of the LFB expects all types of Ethernet packets, including 1716 VLAN Ethernet types. The input is a singleton input which may 1717 connect to an upstream LFB like EtherMACIn LFB. The input is also 1718 capable of multiplexing to allow for multiple upstream LFBs being 1719 connected. For instance, when L2 bridging function is enabled in 1720 EtherMACIn LFB, some L2 bridging LFBs may be applied. In this case, 1721 some Ethernet packets after L2 processing may have to be input to 1722 EtherClassifier LFB for classification, while simultaneously packets 1723 directly output from EtherMACIn may also need to input to this LFB. 1724 Input of this LFB is capable of handling this case. Usually, every 1725 input Ethernet packet is expected to be associated with a PHYPortID 1726 metadatum, indicating the physical port the packet comes from. In 1727 some cases, for instance, like in an MACinMAC case, a LogicalPortID 1728 metadatum may be expected to associate with the Ethernet packet to 1729 further indicate which logical port the Ethernet packet belongs to. 1730 Note that PHYPortID metadata is always expected while LogicalPortID 1731 metadata is optionally expected. 1733 A VLANInputTable component is defined in the LFB to classify VLAN 1734 Ethernet packets. According to IEEE VLAN specifications, all 1735 Ethernet packets can be recognized as VLAN types by defining that if 1736 there is no VLAN encapsulation in a packet, a case with VLAN tag 0 is 1737 considered. Therefore the table actually applies to every input 1738 packet of the LFB. The table assigns every input packet with a new 1739 LogicalPortID according to the packet incoming port ID and the VLAN 1740 ID. A packet incoming port ID is defined as a physical port ID if 1741 there is no logical port ID associated with the packet, or a logical 1742 port ID if there is a logical port ID associated with the packet. 1743 The VLAN ID is exactly the Vlan ID in the packet if it is a VLAN 1744 packet, or 0 if it is not a VLAN packet. Note that a logical port ID 1745 of a packet may be rewritten with a new one by the VLANInputTable 1746 processing. 1748 An EtherDispatchTable component is defined to dispatch every Ethernet 1749 packet to a group of outputs according to the logical port ID 1750 assigned by VLANInputTable to the packet and the Ethernet type in the 1751 Ethernet packet header. By CE configuring the dispatch table, the 1752 LFB can be expected to classify various network layer protocol type 1753 packets and make them output at different output port. It is then 1754 easily expected that the LFB classify packets according to protocols 1755 like IPv4, IPv6, MPLS, ARP, ND, etc. 1757 Output of the LFB is hence defined as a group output. Because there 1758 may be various types of protocol packets at the output ports, the 1759 frameproduced is defined as arbitrary for the purpose of wide 1760 extensibility in the future. In order for downstream LFBs to use, a 1761 bunch of metadata is produced to associate with every output packet. 1762 The medatdata contain normal information like PHYPortID. It also 1763 contains information on Ethernet type, source MAC address, and 1764 destination MAC address of its original Ethernet packet. Moreover, 1765 it contains information of logical port ID assigned by this LFB. 1766 This metadata may be used by downstream LFBs for packet processing. 1767 Lastly, it may conditionally contain information like VlanID and 1768 VlanPriority with the condition that the packet is a VLAN packet. 1770 A MaxOutPutPorts is defined as the capability of the LFB to indicate 1771 how many classification output ports the LFB is capable. 1772 /*discussion*/ 1774 Note that logical port ID and physical port ID mentioned above are 1775 all originally configured by CE, and are globally effective within an 1776 ForCES NE (Network Element). To distinguish a physical port ID from 1777 a logical port ID in the incoming port ID field of the 1778 VLANInputTable, physical port ID and logical port ID must be assigned 1779 with separate number spaces. /*discussion */ 1781 There are also some other components, capabilities, events defined in 1782 the LFB for various purposes. See section 6 for detailed XML 1783 definitions of the LFB. 1785 5.1.4. EtherEncapsulator 1787 EtherEncapsulator LFB abstracts the process to encapsulate IP packets 1788 to Ethernet packets. 1790 Input of the LFB expects types of IP packets, including IPv4 and IPv6 1791 types. The input is a singleton one which may connect to an upstream 1792 LFB like an IPv4NextHop, an IPv6NextHop, or any LFB which requires to 1793 output packets for Ethernet encapsulation. The input is capable of 1794 multiplexing to allow for multiple upstream LFBs being connected. 1795 For instance, an IPv4NextHop or an IPv6NextHop may concurrently 1796 exist, and some L2 bridging LFBs may also output packets to this LFB 1797 simultaneously. Input of this LFB is capable of handling this case. 1798 Usually, every input Ethernet packet is expected to be associated 1799 with an output logical port ID and a next hop IP address as its 1800 metadata. In the case when L2 bridging function is implemented, an 1801 input packet may also optionally receive a VLAN priority as its 1802 metadata. In this case, default value for this metadata is set to 0. 1804 There are several outputs for this LFB. One singleton output is for 1805 normal success packet output. Packets which have found Ethernet L2 1806 information and have been successfully encapsulated to an Ethernet 1807 packet will output from this port to downstream LFB. Note that this 1808 LFB specifies to use Ethernet II as its Ethernet encapsulation type. 1809 Success output also produces an output logical port ID as metadatum 1810 of every output packet for a downstream LFB to decide which logical 1811 port the packet should go out. The downstream LFB usually dispatches 1812 the packets based on its associated output logical port ID. Hence, a 1813 generic dispatch LFB as defined in Section 5.6.1 may be adopted for 1814 dispatching packets based on output logical port ID. 1816 Note that in some implementations of LFBs topology, the processing to 1817 dispatch packets based on an output logical port ID may also take 1818 place before an Ethernet encapsulation,i.e., packets coming into the 1819 encapsulator LFB have already been switched to individual logical 1820 output port paths. In this case, the EtherEncap LFB success output 1821 may be directly connected to a downstream LFB like an EtherMACOut 1822 LFB. 1824 Another singleton output is for IPv4 packets that are unfortunately 1825 unable to find Ethernet L2 encapsulation information by ARP table in 1826 the LFB. In this case, a copy of the packets may need to be 1827 redirected to an ARP LFB in the FE, or to CE if ARP function is 1828 implemented by CE. More importantly, a next hop IP address metadata 1829 should be associated with every packet output here. When an ARP LFB 1830 or CE receives these packets and associated next hop IP address 1831 metadata, it may be expected to generate ARP protocol messages based 1832 on these packets next hop IP addresses to try to get L2 information 1833 for these packets. Refreshed L2 information is then able to be added 1834 in ARP table in this encapsulator LFB by ARP LFB or by CE. As a 1835 result, these packets are then able to successfully find L2 1836 information and be encapsulated to Ethernet packets, and output via 1837 the normal success output to downstream LFB. (Editorial note1: may 1838 need discussion on what more metadata this output packets need? Note 1839 that the packets may be redirected to CE and CE should know what the 1840 purpose of the packets for. A metadata may need to indicate this. 1841 Editorial note2: we may adopt another way to address the case of 1842 packets unable to do ARP. The packets may be redirected to ARP LFB 1843 or CE without keeping a copy of them in this encapsulator LFB. We 1844 expect that after ARP LFB or CE have processed ARP requests based on 1845 the packets, the packets will be redirected back from ARP LFB or CE 1846 to this encapsulator LFB for Ethernet encapsulation. At this time, 1847 it is hoped the ARP table has been refreshed with new L2 information 1848 that will make these packets able to find) 1850 A more singleton output is for IPv6 packets that are unfortunately 1851 unable to find Ethernet L2 encapsulation information by Neighbor 1852 table in the LFB. In this case, a copy of the packets may need to be 1853 redirected to an ND LFB in the FE, or to CE if IPv6 Neighbor 1854 discovery function is implemented by CE. More importantly, a next 1855 hop IP address metadata should be associated with every packet output 1856 here. When the ND LFB or CE receives these packets and associated 1857 next hop IP address metadata, it may be expected to generate neighbor 1858 discovery protocol messages based on these packets next hop IP 1859 addresses to try to get L2 information for these packets. Refreshed 1860 L2 information is then able to be added in neighbor table in this LFB 1861 by ND LFB or by CE. As a result, these packets are then able to 1862 successfully find L2 information and be encapsulated to Ethernet 1863 packets, and output via the normal success output to downstream 1864 LFB.(Editorial note: may need discussion on what more metadata this 1865 output packets need? Note that the packets may be redirected to CE 1866 and CE should know what the purpose of the packets for. A metadata 1867 may need to indicate this) 1869 A singleton output is specifically defined for exception packets 1870 output. All packets that are abnormal during the operations in this 1871 LFB are output via this port. Currently, only one abnormal case is 1872 defined, that is, packets can not find proper information in a VLAN 1873 output table. 1875 The VLAN output table is defined as the component of the LFB. The 1876 table uses a logical port ID as an index to find a VLAN ID and a new 1877 output logical port ID. In reality, the logical port ID applied here 1878 is the output logical port ID received from every input packet in its 1879 associated metadata. According to IEEE VLAN specifications, all 1880 Ethernet packets can be recognized as VLAN types by defining that if 1881 there is no VLAN encapsulation in a packet, a case with VLAN tag 0 is 1882 considered. Therefore, every input IP packet actually has to look up 1883 the VLAN output table to find out a VLAN ID and a new output logical 1884 port ID according to its original logical port ID.. 1886 The ARP table in the LFB is defined as a component of the LFB. The 1887 table is for IPv4 packet to find its next hop Ethernet layer MAC 1888 addresses. Input IPv4 packet will use an output logical port ID 1889 which is got by looking up the VLAN output table, and a next hop IPv4 1890 address which is got by upstream next hop applicator LFB, to look up 1891 the ARP table to find the Ethernet L2 information, i.e., the source 1892 MAC address and destination MAC address. 1894 The neighbor table is defined as another component of the LFB. The 1895 table is for IPv6 packet to find its next hop Ethernet layer MAC 1896 addresses. Like the ARP table, input IPv6 packet will use its output 1897 logical port ID got from looking up the VLAN output table, and the 1898 packet next hop IPv4 address got by upstream next hop applicator LFB, 1899 to look up the neighbor table to find the Ethernet source MAC address 1900 and destination MAC address. 1902 As will be described in the address resolution LFBs section (section 1903 5.4), Layer 2 address resolution protocols may be implemented with 1904 two choices. One is by FE with specific address resolution LFB, like 1905 an ARP LFB or an ND LFB. The other is to redirect address resolution 1906 protocol messages to CE for CE to implement the function. 1908 As described in section 5.4, the ARP LFB defines the ARP table in 1909 this encapsulator LFB as its alias, and the ND LFB defines the 1910 neighbor table as its alias. This means that the ARP table or the 1911 neighbor table will be maintained or refreshed by the ARP LFB or the 1912 ND LFB when the LFBs are used. 1914 Note that the ARP table and the neighbor table defined in this LFB 1915 are all with property of read-write. CE can also configure the 1916 tables by ForCES protocol [RFC5810]. This makes possible that IPv4 1917 ARP protocol or IPv6 Neighbor Discovery protocol may be implemented 1918 at CE side,i.e., after CE manages an ARP or Neighbor discovery 1919 protocol and gets address resolution results, CE can configure them 1920 to an ARP or neighbor table in FE. 1922 With all the information got from VLAN table and ARP or Neighbor 1923 table, input IPv4 or IPv6 packets are then able to be encapsulated to 1924 Ethernet layer packets. Note that according to IEEE 802.1Q, if input 1925 packets are with non-zero VLAN priority metadata, the packets will 1926 always be encapsulated with a VLAN tag, no matter the value of VLAN 1927 ID is zero or not. If the VLAN priority and the VLAN ID are all 1928 zero, the packets will be encapsulated without a VLAN tag. 1930 Successfully encapsulated packets are then output via success output 1931 port. 1933 There are also some other components, capabilities, events defined in 1934 the LFB for various purposes. See section 6 for detailed XML 1935 definitions of the LFB. 1937 5.1.5. EtherMACOut 1939 EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. 1940 This LFB describes Ethernet packet output process. Ethernet output 1941 functions are closely related to Ethernet input functions, therefore 1942 many components defined in this LFB are as aliases of EtherMACIn LFB 1943 components. 1945 5.1.5.1. Data Handling 1947 The LFB is expected to receive all types of Ethernet packets, via a 1948 singleton input known as "EtherPktsIn", which are usually output from 1949 an Ethernet encapsulation LFB, alongside with a metadatum indicating 1950 the physical port ID that the packet will go through(editorial note: 1951 need more discussion on the port ID being physical layer or L2 1952 layer). 1954 The LFB is defined with a singleton output. All Output packets are 1955 in Ethernet format, possibly with various Ethernet types, alongside 1956 with a metadatum indicating the physical port ID the packet is to go 1957 through. This output links to a downstream LFB that is usually an 1958 Ethernet physical LFB like EtherPHYcop LFB. 1960 This LFB can perform Ethernet layer flow control. This is usually 1961 implemented cooperatively by the EtherMACIn LFB and the EtherMACOut 1962 LFB. The flow control is further distinguished by Tx flow control 1963 and Rx flow control, separately for sending process and receiving 1964 process flow control. 1966 Note that as a base definition, functions like multiple virtual MAC 1967 layers are not supported in this LFB version. It may be supported in 1968 the future by defining a subclass or a new version of this LFB 1970 5.1.5.2. Components 1972 The AdminStatus component is defined for CE to administratively 1973 manage the status of the LFB. The CE may administratively startup or 1974 shutdown the LFB by changing the value of AdminStatus. The default 1975 value is set to 'Down'. Note that this component is defined as an 1976 alias of the AdminStatus component in the EtherMACIn LFB. This 1977 infers that an EtherMACOut LFB usually coexists with an EtherMACIn 1978 LFB, both of which share the same administrative status management by 1979 CE. Alias properties as defined in the ForCES FE model (RFC 5812) 1980 will be used by CE to declare the target component this alias refers, 1981 which include the target LFB class and instance IDs as well as the 1982 path to the target component. Whereas, these properties are set by 1983 CE only when a system runs, which are outside the XML definitions of 1984 this LFB. 1986 The MTU component defines the maximum transmission unit 1988 The TxFlowControl component defines whether the LFB is performing 1989 flow control on sending packets. The default value for is 'false'. 1990 Note that this component is defined as an alias of TxFlowControl 1991 component in the EtherMACIn LFB. 1993 The RxFlowControl component defines whether the LFB is performing 1994 flow control on receiving packets. The default value for is 'false'. 1995 Note that this component is defined as an alias of RxFlowControl 1996 component in the EtherMACIn LFB. 1998 A struct component, MACOutStats, defines a set of statistics for this 1999 LFB, including the number of transmitted packets and the number of 2000 dropped packets. 2002 5.1.5.3. Capabilities 2004 This LFB does not have a list of capabilities. 2006 5.1.5.4. Events 2008 This LFB does not have any events specified. 2010 5.2. IP Packet Validation LFBs 2012 The LFBs are defined to abstract IP packet validation process. An 2013 IPv4Validator LFB is specifically for IPv4 protocol validation and an 2014 IPv6Validator LFB for IPv6. 2016 5.2.1. IPv4Validator 2018 The IPv4Validator LFB performs IPv4 packets validation according to 2019 RFC 1812. 2021 5.2.1.1. Data Handling 2023 This LFB performs IPv4 validation according to RFC 1812. Then the 2024 IPv4 packet will be output to the corresponding port regarding of the 2025 validation result, whether the packet is a unicast or a multicast 2026 one, an exception has occurred or the validation failed. 2028 This LFB always expects, as input, packets which have been indicated 2029 as IPv4 packets by an upstream LFB, like an EtherClassifier LFB. 2030 There is no specific metadata expected by the input of the LFB. 2032 Note that, as a default provision of RFC 5812, in FE model, all 2033 metadata produced by upstream LFBs will pass through all downstream 2034 LFBs by default without being specified by input port or output port. 2035 Only those metadata that will be used(consumed) by an LFB will be 2036 explicitly marked in input of the LFB as expected metadata. For 2037 instance, in this LFB, even there is no specific metadata expected, 2038 metadata like PHYPortID produced by some upstream physical layer LFBs 2039 will always pass through this LFB. In some cases, if some component 2040 in the LFB may use the metadata, it actually still can use it 2041 regardless of whether the metadata has been expected or not. 2043 Four output ports are defined to output various validation results. 2045 All validated IPv4 unicast packets will be output at the singleton 2046 port known as "IPv4UnicastOut". All validated IPv4 multicast packets 2047 will be output at the singleton port known as "IPv4MulticastOut" 2048 port. There is no metadata specifically required to produce at these 2049 output ports. 2051 A singleton port known as "ExceptionOut" is defined to output packets 2052 which have been validated as exception packets. An exception ID 2053 metadatum is produced to indicate what has caused the exception. 2054 Currently defined exception types include: 2056 o Packet with destination address equal to 255.255.255.255 2058 o Packet with expired TTL 2060 o Packet with header length more than 5 words 2062 o Packet IP head including Router Alert options 2064 Note that, although TTL is checked in this LFB for validity, 2065 operations to TTL like TTL decreasing will be made only in a followed 2066 forwarding LFB. 2068 The final singleton port known as "FailOut" is defined for all 2069 packets which have failed the validation process. A validate error 2070 ID is associated to every failed packet to indicate the reason. 2071 Currently defined reasons include: 2073 o Packet size reported is less than 20 bytes 2075 o Packet with version is not IPv4 2077 o Packet with header length < 5 2079 o Packet with total length field < 20 2081 o Packet with invalid checksum 2083 o Packet with source address equal to 255.255.255.255 2085 o Packet with source address 0 2087 o Packet with source address of form {127, } 2089 o Packet with source address in Class E domain 2091 5.2.1.2. Components 2093 This LFB has only one struct component, the 2094 IPv4ValidatorStatisticsType, which defines a set of statistics for 2095 validation process, including the number of bad header packets, the 2096 number of bad total length packets, the number of bad TTL packets, 2097 and the number of bad checksum packets. 2099 5.2.1.3. Capabilities 2101 This LFB does not have a list of capabilities 2103 5.2.1.4. Events 2105 This LFB does not have any events specified. 2107 5.2.2. IPv6Validator 2109 The IPv6Validator LFB performs IPv6 packets validation according to 2110 RFC 2460. 2112 5.2.2.1. Data Handling 2114 This LFB performs IPv6 validation according to RFC 2460. Then the 2115 IPv6 packet will be output to the corresponding port regarding of the 2116 validation result, whether the packet is a unicast or a multicast 2117 one, an exception has occurred or the validation failed. 2119 This LFB always expects, as input, packets which have been indicated 2120 as IPv6 packets by an upstream LFB, like an EtherClassifier LFB. 2122 There is no specific metadata expected by the input of the LFB. 2124 Similar to the IPv4validator LFB, IPv6Validator has also defined four 2125 output ports to output packets for various validation results. 2127 All validated IPv6 unicast packets will be output at the singleton 2128 port known as "IPv6UnicastOut". All validated IPv6 multicast packets 2129 will be output at the singleton port known as "IPv6MulticastOut" 2130 port. There is no metadata specifically required to produce at these 2131 output ports. 2133 A singleton port known as "ExceptionOut" is defined to output packets 2134 which have been validated as exception packets. An exception ID 2135 metadata is produced to indicate what caused the exception. 2136 Currently defined exception types include: 2138 o Packet with hop limit to zero 2140 o Packet with a link-local destination address 2142 o Packet with a link-local source address 2144 o Packet with destination all-routers 2146 o Packet with destination all-nodes 2148 o Packet with next header set to Hop-by-Hop 2150 The final singleton port known as "FailOut" is defined for all 2151 packets which have failed the validation process. A validate error 2152 ID is associated to every failed packet to indicate the reason. 2153 Currently defined reasons include: 2155 o Packet size reported is less than 40 bytes 2157 o Packet with version is not IPv6 2159 o Packet with multicast source address (the MSB of the source 2160 address is 0xFF) 2162 o Packet with destination address set to 0 or ::1 2164 o Packet with source address set to loopback (::1). 2166 Note that in the base type library, definitions for exception ID and 2167 validate error ID metadata are applied to both IPv4Validator and 2168 IPv6Validator LFBs, i.e., the two LFBs share the same medadata 2169 definition, with different ID assignment inside. 2171 5.2.2.2. Components 2173 This LFB has only one struct component, the 2174 IPv6ValidatorStatisticsType, which defines a set of statistics for 2175 validation process, including the number of bad header packets, the 2176 number of bad total length packets, and the number of bad hop limit 2177 packets. 2179 5.2.2.3. Capabilities 2181 This LFB does not have a list of capabilities 2183 5.2.2.4. Events 2185 This LFB does not have any events specified. 2187 5.3. IP Forwarding LFBs 2189 IP Forwarding LFBs are specifically defined to abstract the IP 2190 forwarding processes. As definitions for a base LFB library, this 2191 document restricts its LFB definition scope for IP forwarding jobs 2192 only to IP unicast forwarding. LFBs for jobs like IP multicast may 2193 be defined in future versions of the document. 2195 A typical IP unicast forwarding job is usually realized by looking up 2196 some forwarding information table to find some next hop information, 2197 and then based on the next hop information, forwarding packets to 2198 specific output ports. It usually takes two steps to do so, firstly 2199 to look up a forwarding information table by means of Longest Prefix 2200 Matching(LPM) rule to find a next hop index, then to use the index to 2201 look up a next hop information table to find enough information to 2202 submit packets to output ports. This document abstracts the 2203 forwarding processes mainly based on the two steps model. However, 2204 there actually exists other models, like one which may only have a 2205 forwarding information base that have conjoined next hop information 2206 together with forwarding information. In this case, if ForCES 2207 technology is to be applied, some translation work will have to be 2208 done in FE to translate attributes defined by this document into real 2209 attributes the implementation has actually applied. 2211 Based on the IP forwarding abstraction, two kind of typical IP 2212 unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next 2213 hop application LFB. They are further distinguished by IPv4 and IPv6 2214 protocols. 2216 5.3.1. IPv4UcastLPM 2218 The LFB abstracts the process for IPv4 unicast LPM table looking up. 2220 Input of the LFB always expects to receive IPv4 unicast packets. An 2221 IPv4 prefix table is defined as a component for the LFB to provide 2222 forwarding information for every input packet. The destination IPv4 2223 address of every packet is as the index to look up the table with the 2224 rule of longest prefix matching(LPM). A hop selector is the matching 2225 result, which will be output to downstream LFBs as an index for next 2226 hop information. 2228 Normal output of the LFB is a singleton output, which will output 2229 IPv4 unicast packet that has passed the LPM lookup and got a hop 2230 selector as the lookup result. The hop selector is associated with 2231 the packet as a metadatum. Followed the normal output of the LPM LFB 2232 is usually a next hop applicator LFB. The LFB receives packets with 2233 their next hop IDs and based on the next hop IDs to forward the 2234 packets. A hop selector associated with every packet from the normal 2235 output will directly act as a next hop ID for a next hop applicator 2236 LFB.. 2238 The LFB is defined to provide some facilities to support users to 2239 implement equal-cost multi-path routing (ECMP) or reverse path 2240 forwarding (RPF). However, this LFB itself does not provide ECMP or 2241 RPF. To implement ECMP or RPF, additional specific LFBs, like a 2242 specific ECMP LFB, will have to be defined. This work may be done in 2243 the future version of the document. 2245 For the LFB to support ECMP, an ECMP flag is defined in the prefix 2246 table entries. When the flag is set to true, it indicates this table 2247 entry is for ECMP only. In this case, the hop selector in this table 2248 entry will be used as an index for a downstream specific ECMP LFB to 2249 find its correspondent next hop IDs. When ECMP is applied, it will 2250 usually get multiple next hops information. 2252 To distinguish normal output from ECMP case output, a specific ECMP 2253 output is defined. A packet, which has passed through prefix table 2254 entry lookup with true ECMP flag, will always output from this port, 2255 with the hop selector being its lookup result. The output will 2256 usually directly go to a downstream ECMP processing LFB. In the ECMP 2257 LFB, based on the hop selector, multiple next hop IDs may be found, 2258 and more ECMP algorithms may be applied to optimize the route. As 2259 the result of the ECMP LFB, it will output optimized one or multiple 2260 next hop IDs to its downstream LFB that is usually a next hop 2261 applicator LFB. 2263 For the LFB to support RPF, a default route flag is defined in the 2264 prefix table entry. When set true, the prefix entry is identified as 2265 a default route, and also as a forbidden route for RPF. To implement 2266 various RPF, one or more specific LFBs have to be defined. This job 2267 may be done for the future version of the library. 2269 An exception output is defined to allow some exceptional packets to 2270 output here. Exceptions include cases like packets can not find any 2271 routes by the prefix table. 2273 There are also some other components defined in the LFB for various 2274 purposes. See section 6 for detailed XML definitions of the LFB. 2276 5.3.2. IPv4NextHop 2278 This LFB abstracts the process of next hop information application to 2279 IPv4 packets. 2281 The LFB receives an IPv4 packet with an associated next hop ID, and 2282 uses the ID to look up a next hop table to find an appropriate output 2283 port from the LFB. Simultaneously, the LFB also implements TTL 2284 operation and checksum recalculation of every IPv4 packet received. 2286 Input of the LFB is a singleton one which expects to receive IPv4 2287 unicast packets and hop selector metadata from an upstream LFB. 2288 Usually, the upstream LFB is directly an IPv4UnicastLPM LFB_while it 2289 is possible some other upstream LFB may be applied. For instance, 2290 when ECMP is supported, the upstream LFB may be some specific ECMP 2291 LFB. 2293 The next hop ID in hop selector metadata of a packet is then used as 2294 an index to look up a next hop table defined in the LFB. Via this 2295 table and the next hop index, important information for forwarding 2296 the packet is found. Every next hop table entry includes the 2297 following information: 2299 output logical port ID, which will be used by downstream LFBs to 2300 find proper output port. 2302 next hop option, which decides if packets with next hop of this 2303 table entry are destinated to locally attached hosts or not. 2304 Locally attached hosts are hosts in the same subnet with this 2305 router. Next hop option is marked as 'forwarded to locally 2306 attached host' if the next hop entry is for locally attached hosts 2307 delivery. All other next hop entry will be marked with 'normal 2308 forwarding'. If a data packet passes through next hop entries 2309 with its next hop option marked with forwarded to locally attached 2310 host, the next hop IP address metadata associated with the data 2311 packet when output from the LFB will be forced to set to the 2312 destination IP address of the data packet. If a data packet 2313 passes through a next hop entry with its option being normal 2314 forwarding, the next hop IP address metadata at output will be set 2315 to the next hop IP address as indicated by this next hop entry. 2316 Advantage to define this next hop option for locally attached 2317 hosts is, in this way, the next hop entry number may be greatly 2318 reduced in the case there are a vast number of locally attached 2319 hosts. 2321 next hop IP address, which will be used by downstream LFB to find 2322 proper output port IP address for this packet. Note that when 2323 next hop option is set to 'forwarded to locally attached host', 2324 this entry field becomes invalid. In this case the next hop IP 2325 address is assigned directly by destination IP address of the data 2326 packet pass through this entry check. 2328 encapsulation output index, which is used by data packet to find 2329 proper output of this LFB. Usually, this index can be used to 2330 indicate which encapsulation followed the LFB may be applied to 2331 data packets pass through this next hop entry check and to 2332 classify the packets to different instance of a group output port. 2333 Moreover, this index can also be used to purely indicate output 2334 port instance to act as a classifier based on next hop IDs. For 2335 instance, a next hop table entry can be defined with its 2336 encapsulation output index being directed to an output port which 2337 is followed with LFBs that will redirect data packets to Control 2338 Element(CE). A next hop entry can also be defined for some data 2339 packets that need special local processing of the Forwarding 2340 Element(FE). In this case it is not really acting as an 2341 encapsulation index, rather a pure output index. 2343 As a result, the LFB is defined with two output ports. One is for 2344 success output and another is for exception output. Success output 2345 is a group output, with an index to indicate which output instance in 2346 the group is adopted. The index is exactly the encapsulation output 2347 index described above. Downstream LFBs connected to the success 2348 output group may be various LFBs for encapsulation like LFBs for 2349 Ethernet encapsulation and for PPP encapsulation, various LFBs for 2350 local processing, and LFBs for redirecting packets to CE for 2351 processing. Next hop table uses the encapsulation output index to 2352 indicate which port instance in the output group a packet should go. 2354 Every port instance of the success output group will produce metadata 2355 of output logical port ID and next hop IP address for every output 2356 packet. These metadata will be used by downstream LFBs to further 2357 implementing forwarding or local processing. Note that for next hop 2358 option marked as local host processing, the next hop IP address 2359 metadata for the packet is exactly substituted with the destination 2360 IP address of the packet. 2362 The exception output of the LFB is a singleton output. It outputs 2363 packets with exceptional cases. An exception ID further indicates 2364 the exception reasons. Exception may happen when a hop selector is 2365 found invalid, or ICMP packets need to be generated (Editorial note: 2366 more discussions here), etc. The exception ID is also produced as a 2367 metadata by the output to be transmitted to a downstream LFB. 2369 There are also some other components defined in the LFB for various 2370 purposes. See section 6 for detailed XML definitions of the LFB. 2372 5.3.3. IPv6UcastLPM 2374 The LFB abstracts the process for IPv6 unicast LPM table looking up. 2376 Definitions of this IPv6UcastLPM LFB is very identical to 2377 IPv4UcastLPM LFB except that all IP addresses related are changed 2378 from IPv4 addresses to IPv6 addresses. See section 6 for detailed 2379 XML definitions of this LFB. 2381 5.3.4. IPv6NextHop 2383 This LFB abstracts the process of next hop information application to 2384 IPv6 packets. 2386 Definitions of this IPv6NextHop LFB is very identical to IPv4NextHop 2387 LFB except that all IP addresses related are changed from IPv4 2388 addresses to IPv6 addresses. See section 6 for detailed XML 2389 definitions of this LFB. 2391 5.4. Redirect LFBs 2393 Redirect LFBs abstract data packets transportation process between CE 2394 and FE. Some packets output from some LFBs may have to be delivered 2395 to CE for further processing, and some packets generated by CE may 2396 have to be delivered to FE and further to some specific LFBs for data 2397 path processing. According to RFC 5810 [RFC5810], data packets and 2398 their associated metadata are encapsulated in ForCES redirect message 2399 for transportation between CE and FE. We define two LFBs to abstract 2400 the process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an 2401 LFB topology of an FE, only one RedirectIn LFB instance and one 2402 RedirectOut LFB instance exist. 2404 5.4.1. RedirectIn 2406 A RedirectIn LFB abstracts the process for CE to inject data packets 2407 into FE LFB topology so as to input data packets into FE data paths. 2409 From LFB topology point of view, the RedirectIn LFB acts as a source 2410 point for data packets coming from CE, therefore the RedirectIn LFB 2411 is defined with only one output, while without any input. 2413 Output of the RedirectIn LFB is defined as a group output. Packets 2414 produced by the output will have arbitrary frame types decided by CE 2415 which generates the packets. Possible frames may include IPv4, IPv6, 2416 or ARP protocol packets. CE may associate some metadata to indicate 2417 the frame types. CE may also associate other metadata to data 2418 packets to indicate various information on the packets. Among them, 2419 there MUST exist a 'RedirectIndex' metadata, which is an integer 2420 acting as an index. When CE transmits the metadata and a binging 2421 packet to a RedirectIn LFB, the LFB will read the metadata and output 2422 the packet to one of its group output port instance, whose port index 2423 is just as indicated by the metadata. Detailed XML definition of the 2424 metadata is in the XML for base type library as in Section 4.4. 2426 All metadata from CE other than the 'RedirectIndex' metadata will 2427 output from the RedirectIn LFB along with their binding packets. 2428 Note that, a packet without a 'RedirectIndex' metadata associated 2429 will be dropped by the LFB. 2431 There is no component defined for current version of RedirectIn LFB. 2432 Detailed XML definitions of the LFB can be found in Section 6. 2434 5.4.2. RedirectOut 2436 A RedirectOut LFB abstracts the process for LFBs in FE to deliver 2437 data packets to CE. From LFB topology point of view, the RedirectOut 2438 LFB acts as a sink point for data packets going to CE, therefore the 2439 RedirectOut LFB is defined with only one input, while without any 2440 output. 2442 Input of the RedirectOut LFB is defined as a singleton input, but it 2443 is capable of receiving packets from multiple LFBs by multiplexing 2444 the singleton input. Packets expected by the input will have 2445 arbitrary frame types. All metadata associated with the input 2446 packets will be delivered to CE via a ForCES protocol redirect 2447 message [RFC5810]. The input will expect all types of metadata. 2449 There is no component defined for current version of RedirectOut LFB. 2450 Detailed XML definitions of the LFB can be found in Section 6. 2452 5.5. General Purpose LFBs 2453 5.5.1. BasicMetadataDispatch 2455 A basic medatata dispatch LFB is defined to abstract a process in 2456 which a packet is dispatched to some path based on its associated 2457 metadata value. 2459 The LFB is with a singleton input. Packets of arbitrary frame types 2460 can input into the LFB. Whereas, every input packet is required to 2461 be associated with a metadata that will be used by the LFB to do 2462 dispatch. If a packet is not associated with such metadata, the 2463 packet will be dropped inside the LFB. 2465 A group of output is defined to output packets according to a 2466 MetaDispatchTable as defined a component in the LFB. The table 2467 contains the fields of a metadata ID, a metadata value, and an output 2468 port index. A packet, if it is associated with a metadata with the 2469 metadata ID, will be output to the group port instance with the index 2470 corresponding to the metadata value in the table. The metadata value 2471 ussed by the table is required with an interger data type. This 2472 means this LFB currently only allow a metadata with an interger value 2473 to be used for dispatch. 2475 Moreover, the LFB is defined with only one metadata adopted for 2476 dispatch, i.e., the metadata ID in the dispatch table is always the 2477 same for all table rows. 2479 A more complex metadata dispatch LFB may be defined in future version 2480 of the library. In that LFB, multiple tuples of metadata may be 2481 adopted to dispatch packets. 2483 5.5.2. GenericScheduler 2485 There exist various kinds of scheduling strategies with various 2486 implementations. As a base LFB library, this document only defines a 2487 preliminary generic scheduler LFB for abstracting a simple scheduling 2488 process. The generic scheduler LFB is the one. Users may use this 2489 LFB as a basic scheduler LFB to further construct more complex 2490 scheduler LFBs by means of inheritance as described in RFC 5812 2491 [RFC5812]. 2493 The LFB describes scheduling process in the following model: 2495 o It is with a group input and expects packets with arbitrary frame 2496 types to arrive for scheduling. The group input is capable of 2497 multiple input port instances. Each port instance may be 2498 connected to different upstream LFB output. No metadata is 2499 expected for each input packet. 2501 o Multiple queues reside at the input side, with every input port 2502 instance connected to one queue. 2504 o Every queue is marked with a queue ID, and the queue ID is exactly 2505 the same as the index of corresponding input port instance. 2507 o Scheduling disciplines are applied to all queues and also all 2508 packets in the queues. 2510 o Scheduled packets are output from a singleton output port of the 2511 LFB. 2513 Two LFB components are defined to further describe above model. A 2514 scheduling discipline component is defined for CE to specify a 2515 scheduling discipline to the LFB. Currently defined scheduling 2516 disciplines only include FIFO and round robin(RR). For FIFO, we 2517 limit above model that when a FIFO discipline is applied, it is 2518 require that there is only one input port instance for the group 2519 input. If user accidentally defines multiple input port instances 2520 for FIFO scheduling, only packets in the input port with lowest port 2521 index will be scheduled to output port, and all packets in other 2522 input port instances will just ignored. 2524 We specify that if the generic scheduler LFB is defined only one 2525 input port instance, the default scheduling discipline is FIFO. If 2526 the LFB is defined with more than one input port instances, the 2527 default scheduling discipline is round robin (RR). 2529 A current queue depth component is defined to allow CE to query every 2530 queue status of the scheduler. Using the queue ID as the index, CE 2531 can query every queue for its used length in unit of packets or 2532 bytes. 2534 Several capabilities are defined for the LFB. A queue number limit 2535 is defined which limits the scheduler maximum supported queue number, 2536 which is also the maximum number of input port instances. Capability 2537 of disciplines supported provides scheduling discipline types 2538 supported by the FE to CE. Queue length limit provides the 2539 capability of storage ability for every queue. 2541 More complex scheduler LFB may be defined with more complex 2542 scheduling discipline by succeeding this LFB. For instance, a 2543 priority scheduler LFB may be defined only by inheriting this LFB and 2544 define a component to indicate priorities for all input queues. 2546 See Section 6 for detailed XML definition for this LFB. 2548 6. XML for LFB Library 2550 2553 2554 2555 2556 EtherPHYCop 2557 The LFB describes an Ethernet port abstracted at 2558 physical layer.It limits its physical media to copper. 2559 Multiple virtual PHYs isn't supported in this LFB version. 2560 2561 1.0 2562 2563 2564 EtherPHYIn 2565 The input port of the EtherPHYCop LFB. It 2566 expects any kind of Ethernet frame. 2567 2568 2569 EthernetAll 2570 2571 2572 2573 2574 2575 2576 EtherPHYOut 2577 The output port of the EtherPHYCop LFB. It 2578 can produce any kind of Ethernet frame and along with 2579 the frame passes the ID of the Physical Port as 2580 metadata to be used by the next LFBs. 2581 2582 2583 EthernetAll 2584 2585 2586 PHYPortID 2587 2588 2589 2590 2591 2592 2593 PHYPortID 2594 The ID of the physical port that this LFB 2595 handles. 2596 uint32 2597 2598 2599 AdminStatus 2600 Admin status of the LFB 2601 PortStatusValues 2602 2 2603 2604 2605 OperStatus 2606 Operational status of the LFB. 2607 PortStatusValues 2608 2609 2610 AdminLinkSpeed 2611 The link speed that the admin has requested. 2612 2613 LANSpeedType 2614 0x00000005 2615 2616 2617 OperLinkSpeed 2618 The actual operational link speed. 2619 LANSpeedType 2620 2621 2622 AdminDuplexMode 2623 The duplex mode that the admin has requested. 2624 2625 DuplexType 2626 0x00000001 2627 2628 2629 OperDuplexMode 2630 The actual duplex mode. 2631 DuplexType 2632 2633 2634 CarrierStatus 2635 The status of the Carrier. Whether the port 2636 is linked with an operational connector. 2637 boolean 2638 false 2639 2640 2641 2642 2643 SupportedLinkSpeed 2644 Supported Link Speeds 2645 2646 LANSpeedType 2647 2648 2649 2650 SupportedDuplexMode 2651 Supported Duplex Modes 2652 2653 DuplexType 2654 2655 2656 2657 2658 2659 PHYPortStatusChanged 2660 When the status of the Physical port is 2661 changed,the LFB sends the new status. 2662 2663 OperStatus 2664 2665 2666 2667 2668 OperStatus 2669 2670 2671 2672 2673 LinkSpeedChanged 2674 When the operational speed of the link 2675 is changed, the LFB sends the new operational link 2676 speed. 2677 2678 OperLinkSpeed 2679 2680 2681 2682 2683 OperLinkSpeed 2684 2685 2686 2687 2688 DuplexModeChanged 2689 When the operational duplex mode 2690 is changed, the LFB sends the new operational mode. 2692 2693 2694 OperDuplexMode 2695 2696 2697 2698 2699 OperDuplexMode 2700 2701 2702 2703 2704 2705 2706 EtherMACIn 2707 An LFB abstracts an Ethernet port at MAC data link 2708 layer. It specifically describes Ethernet processing functions 2709 like MAC address locality check, deciding if the Ethernet 2710 packets should be bridged, provide Ethernet layer flow control, 2711 etc.Multiple virtual MACs isn't supported in this LFB 2712 version. 2713 1.0 2714 2715 2716 EtherMACIn 2717 The input port of the EtherMACIn. It 2718 expects any kind of Ethernet frame. 2719 2720 2721 EthernetAll 2722 2723 2724 PHYPortID 2725 2726 2727 2728 2729 2730 2731 NormalPathOut 2732 The normal output port of the EtherMACIn. 2733 It can produce any kind of Ethernet frame and along 2734 with the frame passes the ID of the Physical Port as 2735 metadata to be used by the next LFBs. 2736 2737 2738 EthernetAll 2739 2740 2741 PHYPortID 2742 2743 2744 2745 2746 L2BridgingPathOut 2747 The Bridging Output Port of the EtherMACIn. 2748 It can produce any kind of Ethernet frame and along 2749 with the frame passes the ID of the Physical Port as 2750 metadata to be used by the next LFBs. 2751 2752 2753 EthernetAll 2754 2755 2756 PHYPortID 2757 2758 2759 2760 2761 2762 2763 AdminStatus 2764 Admin status of the port 2765 PortStatusValues 2766 2 2767 2768 2769 LocalMACAddresses 2770 Local Mac addresses 2771 2772 IEEEMAC 2773 2774 2775 2776 L2BridgingPathEnable 2777 Is the LFB doing L2 Bridging? 2778 boolean 2779 false 2780 2781 2782 PromiscuousMode 2783 Is the LFB in Promiscuous Mode? 2784 boolean 2785 false 2786 2787 2788 TxFlowControl 2789 Transmit flow control 2790 boolean 2791 false 2792 2793 2794 RxFlowControl 2795 Receive flow control 2796 boolean 2797 false 2798 2799 2800 MACInStats 2801 MACIn statistics 2802 MACInStatsType 2803 2804 2805 2806 2807 EtherClassifier 2808 This LFB abstracts the process to decapsulate 2809 Ethernet packets and classify the data packets into 2810 various network layer data packets according to information 2811 included in the Ethernet packets headers. 2812 1.0 2813 2814 2815 EtherPktsIn 2816 Input port for data packet. 2817 2818 2819 EthernetAll 2820 2821 2822 PHYPortID 2823 2824 LogicalPortID 2825 2826 2827 2828 2829 2830 2831 ClassifyOut 2832 Output port for classification. 2833 2834 2835 Arbitrary 2837 2838 2839 PHYPortID 2840 SrcMAC 2841 DstMAC 2842 EtherType 2843 VlanID 2844 VlanPriority 2845 2846 2847 2848 2849 2850 2851 EtherDispatchTable 2852 Ether classify dispatch table 2853 EtherDispatchTableType 2854 2855 2856 VlanInputTable 2857 Vlan input table 2858 VlanInputTableType 2859 2860 2861 EtherClassifyStats 2862 Ether classify statistic table 2863 EtherClassifyStatsTableType 2864 2865 2866 2867 2868 EtherEncapsulator 2869 This LFB abstracts the process to encapsulate IP 2870 packets to Ethernet packets according to the L2 information. 2871 2872 1.0 2873 2874 2875 EncapIn 2876 A Single Packet Input 2877 2878 2879 IPv4 2880 IPv6 2881 2882 2883 MediaEncapInfoIndex 2884 2885 VlanPriority 2886 2887 2888 2889 2890 2891 2892 SuccessOut 2893 Output port for Packets which have found 2894 Ethernet L2 information and have been successfully 2895 encapsulated to an Ethernet packet. 2896 2897 2898 IPv4 2899 IPv6 2900 2901 2902 L2PortID 2903 2904 2905 2906 2907 ExceptionOut 2908 All packets that fail with the other 2909 operations in this LFB are output via this port. 2910 2911 2912 2913 IPv4 2914 IPv6 2915 2916 2917 ExceptionID 2918 MediaEncapInfoIndex 2919 VlanPriority 2920 2921 2922 2923 2924 2925 2926 EncapTable 2927 Ethernet Encapsulation table. 2928 EncapTableType 2929 2930 2931 2932 2933 EtherMACOut 2934 EtherMACOut LFB abstracts an Ethernet port at MAC 2935 data link layer. It specifically describes Ethernet packet 2936 output process. Ethernet output functions are closely related 2937 to Ethernet input functions, therefore some components 2938 defined in this LFB are actually alias of EtherMACIn LFB. 2939 2940 1.0 2941 2942 2943 EtherPktsIn 2944 The Input Port of the EtherMACIn. It expects 2945 any kind of Ethernet frame. 2946 2947 2948 EthernetAll 2949 2950 2951 PHYPortID 2952 2953 2954 2955 2956 2957 2958 EtherMACOut 2959 The Normal Output Port of the EtherMACOut. It 2960 can produce any kind of Ethernet frame and along with 2961 the frame passes the ID of the Physical Port as 2962 metadata to be used by the next LFBs. 2963 2964 2965 EthernetAll 2966 2967 2968 PHYPortID 2969 2970 2971 2972 2973 2974 2975 AdminStatus 2976 Admin status of the port. It is the alias of 2977 "AdminStatus" component defined in EtherMACIn. 2978 2979 PortStatusValues 2980 2981 2982 MTU 2983 Maximum transmission unit. 2984 uint32 2985 2986 2987 TxFlowControl 2988 Transmit flow control. It is the alias of 2989 "TxFlowControl" component defined in EtherMACIn. 2990 2991 boolean 2992 2993 2994 RxFlowControl 2995 Receive flow control. It is the alias of 2996 "RxFlowControl" component defined in EtherMACIn. 2997 2998 boolean 2999 3000 3001 MACOutStats 3002 MACOut statistics 3003 MACOutStatsType 3004 3005 3006 3007 3008 IPv4Validator 3009 An LFB that performs IPv4 packets validation 3010 according to RFC1812. At the same time, ipv4 unicast and 3011 multicast are classified in this LFB. 3012 1.0 3013 3014 3015 ValidatePktsIn 3016 Input port for data packet. 3017 3018 3019 Arbitrary 3020 3021 3022 3023 3024 3025 3026 IPv4UnicastOut 3027 Output for IPv4 unicast packet. 3028 3029 3030 IPv4Unicast 3031 3032 3033 3034 3035 IPv4MulticastOut 3036 Output for IPv4 multicast packet. 3037 3038 3039 IPv4Multicast 3040 3041 3042 3043 3044 ExceptionOut 3045 Output for exception packet. 3046 3047 3048 IPv4 3049 3050 3051 ExceptionID 3052 3053 3054 3055 3056 FailOut 3057 Output for failed validation packet. 3058 3059 3060 3061 IPv4 3062 3063 3064 ValidateErrorID 3065 3066 3067 3068 3069 3070 3071 IPv4ValidatorStats 3072 IPv4 validator statistics information. 3073 3074 IPv4ValidatorStatisticsType 3075 3076 3078 3079 3080 IPv6Validator 3081 An LFB that performs IPv6 packets validation 3082 according to RFC2460. At the same time, ipv6 unicast and 3083 multicast are classified in this LFB. 3084 1.0 3085 3086 3087 ValidatePktsIn 3088 Input port for data packet. 3089 3090 3091 Arbitrary 3092 3093 3094 3095 3096 3097 3098 IPv6UnicastOut 3099 Output for IPv6 unicast packet. 3100 3101 3102 IPv6Unicast 3103 3104 3105 3106 3107 IPv6MulticastOut 3108 Output for IPv6 multicast packet. 3109 3110 3111 IPv6Multicast 3112 3113 3114 3115 3116 ExceptionOut 3117 Output for exception packet. 3118 3119 3120 IPv6 3121 3122 3123 ExceptionID 3124 3125 3127 3128 3129 FailOut 3130 Output for failed validation packet. 3131 3132 3133 3134 IPv6 3135 3136 3137 ValidateErrorID 3138 3139 3140 3141 3142 3143 3144 IPv6ValidatorStats 3145 IPv6 validator statistics information. 3146 3147 IPv6ValidatorStatisticsType 3148 3149 3150 3151 3152 IPv4UcastLPM 3153 An LFB that performs IPv4 Longest Prefix Match 3154 Lookup.It is defined to provide some facilities to support 3155 users to implement equal-cost multi-path routing(ECMP) or 3156 reverse path forwarding (RPF). 3157 1.0 3158 3159 3160 PktsIn 3161 A Single Packet Input 3162 3163 3164 IPv4Unicast 3165 3166 3167 3168 3169 3170 3171 NormalOut 3172 This output port is connected with 3173 IPv4NextHop LFB 3174 3175 3176 IPv4Unicast 3177 3178 3179 HopSelector 3180 3181 3182 3183 3184 ECMPOut 3185 This output port is connected with ECMP LFB, 3186 if there is ECMP LFB in the FE. 3187 3188 3189 IPv4Unicast 3190 3191 3192 HopSelector 3193 3194 3195 3196 3197 ExceptionOut 3198 The output for the packet if an exception 3199 occurs 3200 3201 3202 IPv4Unicast 3203 3204 3205 ExceptionID 3206 3207 3208 3209 3210 3211 3212 IPv4PrefixTable 3213 The IPv4 prefix table. 3214 IPv4PrefixTableType 3215 3216 3217 IPv4UcastLPMStats 3218 Statistics for IPv4 Unicast Longest Prefix 3219 Match 3220 IPv4UcastLPMStatsType 3221 3222 3224 3225 3226 IPv6UcastLPM 3227 An LFB that performs IPv6 Longest Prefix Match 3228 Lookup.It is defined to provide some facilities to support 3229 users to implement equal-cost multi-path routing(ECMP) or 3230 reverse path forwarding (RPF). 3231 1.0 3232 3233 3234 PktsIn 3235 A Single Packet Input 3236 3237 3238 IPv6Unicast 3239 3240 3241 3242 3243 3244 3245 NormalOut 3246 This output port is connected with 3247 IPv6NextHop LFB 3248 3249 3250 IPv6Unicast 3251 3252 3253 HopSelector 3254 3255 3256 3257 3258 ECMPOut 3259 This output port is connected with ECMP LFB, 3260 if there is ECMP LFB in the FE. 3261 3262 3263 IPv6Unicast 3264 3265 3266 HopSelector 3267 3268 3269 3270 3271 ExceptionOut 3272 The output for the packet if an exception 3273 occurs 3274 3275 3276 IPv6Unicast 3277 3278 3279 ExceptionID 3280 3281 3282 3283 3284 3285 3286 IPv6PrefixTable 3287 The IPv6 prefix table. 3288 IPv6PrefixTableType 3289 3290 3291 IPv6UcastLPMStats 3292 Statistics for IPv6 Unicast Longest Prefix 3293 Match 3294 IPv6UcastLPMStatsType 3295 3296 3297 3298 3299 IPv4NextHop 3300 This LFB abstracts the process of selecting ipv4 3301 next hop action. It receives an IPv4 packet with an 3302 associated next hop ID, and uses the ID to look up a next 3303 hop table to find an appropriate output port from the LFB. 3304 3305 1.0 3306 3307 3308 PktsIn 3309 A Single Packet Input 3310 3311 3312 IPv4Unicast 3313 3314 3315 HopSelector 3316 3317 3318 3319 3320 3321 3322 SuccessOut 3323 The output for the packet if it is valid to be 3324 forwarded 3325 3326 3327 IPv4Unicast 3328 3329 3330 OutputLogicalPortID 3331 NextHopIPv4Addr 3332 3333 3334 3335 3336 ExceptionOut 3337 The output for the packet if an exception 3338 occurs 3339 3340 3341 IPv4Unicast 3342 3343 3344 ExceptionID 3345 3346 3347 3348 3349 3350 3351 IPv4NextHopTable 3352 The next hop table. 3353 IPv4NextHopTableType 3354 3355 3356 3357 3358 IPv6NextHop 3359 The LFB abstracts the process of next hop 3360 information application to IPv6 packets. It receives an IPv4 3361 packet with an associated next hop ID, and uses the ID to 3362 look up a next hop table to find an appropriate output port 3363 from the LFB.. 3364 1.0 3365 3366 3367 PktsIn 3368 A single packet input. 3369 3370 3371 IPv6Unicast 3372 3373 3374 HopSelector 3375 3376 3377 3378 3379 3380 3381 SuccessOut 3382 The output for the packet if it is valid to 3383 be forwarded 3384 3385 3386 IPv6Unicast 3387 3388 3389 OutputLogicalPortID 3390 NextHopIPv6Addr 3391 3392 3393 3394 3395 ExceptionOut 3396 The output for the packet if an exception 3397 occurs 3398 3399 3400 IPv6Unicast 3401 3402 3403 ExceptionID 3404 3405 3406 3407 3408 3409 3410 IPv6NextHopTable 3411 The next hop table. 3412 IPv6NextHopTableType 3413 3414 3415 3416 3417 RedirectIn 3418 The RedirectIn LFB abstracts the process for CE to 3419 inject data packets into FE LFB topology, so as to input data 3420 packets into FE data paths. CE may associate some 3421 metadata to data packets to indicate various information on 3422 the packets. Among them, there MUST exist a 'RedirectIndex' 3423 metadata, which is an integer acting as an output port index. 3424 3425 1.0 3426 3427 3428 PktsOut 3429 This output group sends the redirected packet 3430 in the data path. 3431 3432 3433 Arbitrary 3434 3435 3436 3437 3438 3439 3440 RedirectOut 3441 The LFB abstracts the process for LFBs in 3442 FE to deliver data packets to CE. All metadata 3443 associated with the input packets will be delivered to CE 3444 via the redirect message of ForCES protocol [RFC5810]. 3445 3446 1.0 3447 3448 3449 PktsIn 3450 This input receives packets to send to 3451 the CE. 3452 3453 3454 Arbitrary 3455 3456 3457 3458 3459 3460 3461 BasicMetadataDispatch 3462 This LFB provides the function to dispatch input 3463 packets to a group output according to a metadata and a 3464 dispatch table.This LFB currently only allow a metadata with 3465 an interger value to be used for dispatch. 3466 1.0 3467 3468 3469 PktsIn 3470 Input port for data packet. 3471 3472 3473 Arbitrary 3474 3475 3476 Arbitrary 3477 3478 3479 3480 3481 3482 3483 PktsOut 3484 Data packet output 3485 3486 3487 Arbitrary 3488 3489 3490 3491 3492 3493 3494 MetadataDispatchTable 3495 Metadata dispatch table. 3496 MetadataDispatchTableType 3497 3498 3499 3500 3501 GenericScheduler 3502 This is a preliminary generic scheduler LFB for 3503 abstracting a simple scheduling process.Users may use this 3504 LFB as a basic scheduler LFB to further construct more 3505 complex scheduler LFBs by means of inheritance as described 3506 in RFC 5812. 3507 1.0 3508 3509 3510 PktsIn 3511 Input port for data packet. 3512 3513 3514 Arbitrary 3515 3516 3517 3518 3519 3520 3521 PktsOut 3522 Data packet output. 3523 3524 3525 Arbitrary 3526 3527 3528 3529 3530 3531 3532 QueueCount 3533 The number of queues to be scheduled. 3534 3535 uint32 3536 3537 3538 SchedulingDiscipline 3539 the Scheduler discipline. 3540 SchdDisciplineType 3541 3542 3543 CurrentQueueDepth 3544 Current Depth of all queues 3545 QueueDepthTableType 3546 3547 3548 3549 3550 QueueLenLimit 3551 Maximum length of each queue,the unit is 3552 byte. 3553 uint32 3554 3555 3556 QueueScheduledLimit 3557 Max number of queues that can be scheduled 3558 by this scheduluer. 3559 uint32 3561 3562 3563 DisciplinesSupported 3564 the scheduling disciplines supported. 3565 3566 3567 SchdDisciplineType 3568 3569 3570 3571 3572 3573 3574 7. LFB Class Use Cases 3576 This section demonstrates examples on how the LFB classes defined by 3577 the Base LFB library in Section 6 are applied to achieve typical 3578 router functions. 3580 As mentioned in the overview section, typical router functions can be 3581 categorized in short into the following functions: 3583 o IP forwarding 3585 o address resolution 3587 o ICMP 3589 o network management 3591 o running routing protocol 3593 To achieve the functions, processing paths organized by the LFB 3594 classes with their interconnections should be established in FE. In 3595 general, CE controls and manages the processing paths by use of the 3596 ForCES protocol. 3598 Note that LFB class use cases shown in this section are only as 3599 examples to demonstrate how typical router functions can be 3600 implemented with the defined base LFB library. Users and 3601 implementers should not be limited by the examples. 3603 7.1. IP Forwarding 3605 TBD 3607 8. Contributors 3609 The authors would like to thank Jamal Hadi Salim, Ligang Dong, and 3610 Fenggen Jia who made major contributions to the development of this 3611 document. 3613 Jamal Hadi Salim 3614 Mojatatu Networks 3615 Ottawa, Ontario 3616 Canada 3617 Email: hadi@mojatatu.com 3619 Ligang Dong 3620 Zhejiang Gongshang University 3621 149 Jiaogong Road 3622 Hangzhou 310035 3623 P.R.China 3624 Phone: +86-571-28877751 3625 EMail: donglg@mail.zjgsu.edu.cn 3627 Fenggen Jia 3628 National Digital Switching Center(NDSC) 3629 Jianxue Road 3630 Zhengzhou 452000 3631 P.R.China 3632 EMail: jfg@mail.ndsc.com.cn 3634 9. Acknowledgements 3636 This document is based on earlier documents from Joel Halpern, Ligang 3637 Dong, Fenggen Jia and Weiming Wang. 3639 10. IANA Considerations 3641 (TBD) 3643 11. Security Considerations 3645 These definitions if used by an FE to support ForCES create 3646 manipulable entities on the FE. Manipulation of such objects can 3647 produce almost unlimited effects on the FE. FEs should ensure that 3648 only properly authenticated ForCES protocol participants are 3649 performing such manipulations. Thus the security issues with this 3650 protocol are defined in the ForCES protocol [RFC5810]. 3652 12. References 3654 12.1. Normative References 3656 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 3657 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 3658 Control Element Separation (ForCES) Protocol 3659 Specification", RFC 5810, March 2010. 3661 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 3662 Element Separation (ForCES) Forwarding Element Model", 3663 RFC 5812, March 2010. 3665 12.2. Informative References 3667 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 3668 RFC 1812, June 1995. 3670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3671 Requirement Levels", BCP 14, RFC 2119, March 1997. 3673 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3674 June 1999. 3676 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3677 Text on Security Considerations", BCP 72, RFC 3552, 3678 July 2003. 3680 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3681 of IP Control and Forwarding", RFC 3654, November 2003. 3683 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3684 "Forwarding and Control Element Separation (ForCES) 3685 Framework", RFC 3746, April 2004. 3687 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3688 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3689 May 2008. 3691 Authors' Addresses 3693 Weiming Wang 3694 Zhejiang Gongshang University 3695 18 Xuezheng Str., Xiasha University Town 3696 Hangzhou, 310018 3697 P.R.China 3699 Phone: +86-571-28877721 3700 Email: wmwang@zjgsu.edu.cn 3702 Evangelos Haleplidis 3703 University of Patras 3704 Patras, 3705 Greece 3707 Email: ehalep@ece.upatras.gr 3709 Kentaro Ogawa 3710 NTT Corporation 3711 Tokyo, 3712 Japan 3714 Email: ogawa.kentaro@lab.ntt.co.jp 3716 Chuanhuang Li 3717 Hangzhou BAUD Networks 3718 408 Wen-San Road 3719 Hangzhou, 310012 3720 P.R.China 3722 Phone: +86-571-28877751 3723 Email: chuanhuang_li@zjgsu.edu.cn 3725 Halpern Joel 3726 Ericsson 3727 P.O. Box 6049 3728 Leesburg, 20178 3729 VA 3731 Phone: +1 703 371 3043 3732 Email: joel.halpern@ericsson.com