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