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