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