draft-ietf-forces-lfb-lib-04.txt   draft-ietf-forces-lfb-lib-05.txt 
Internet Engineering Task Force W. Wang Internet Engineering Task Force W. Wang
Internet-Draft Zhejiang Gongshang University Internet-Draft Zhejiang Gongshang University
Intended status: Standards Track E. Haleplidis Intended status: Standards Track E. Haleplidis
Expires: December 4, 2011 University of Patras Expires: January 11, 2012 University of Patras
K. Ogawa K. Ogawa
NTT Corporation NTT Corporation
C. Li C. Li
Hangzhou BAUD Networks Hangzhou BAUD Networks
J. Halpern J. Halpern
Ericsson Ericsson
June 2, 2011 July 10, 2011
ForCES Logical Function Block (LFB) Library ForCES Logical Function Block (LFB) Library
draft-ietf-forces-lfb-lib-04 draft-ietf-forces-lfb-lib-05
Abstract Abstract
This document defines basic classes of Logical Function Blocks (LFBs) This document defines basic classes of Logical Function Blocks (LFBs)
used in the Forwarding and Control Element Separation (ForCES). It used in the Forwarding and Control Element Separation (ForCES). The
is defined according to ForCES FE model [RFC5812] and ForCES protocol basic LFB classes are defined according to ForCES FE model [RFC5812]
[RFC5810] specifications. These basic LFB classes are scoped to meet and ForCES protocol [RFC5810] specifications, and are scoped to meet
requirements of typical router functions and considered as the basic requirements of typical router functions and considered as the basic
LFB library for ForCES. Descriptions of individual LFBs are LFB library for ForCES. The library includes the descriptions of the
presented and detailed XML definitions are included in the library. LFBs and the XML definitions.
Several use cases of the defined LFB classes are also proposed.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2011. This Internet-Draft will expire on January 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Scope of the Library . . . . . . . . . . . . . . . . . . . 7 3.1. Scope of the Library . . . . . . . . . . . . . . . . . . . 7
3.2. Overview of LFB Classes in the Library . . . . . . . . . . 9 3.2. Overview of LFB Classes in the Library . . . . . . . . . . 9
3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . . 9 3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . . 9
3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 9 3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 9
3.2.3. Sample LFB Class Application . . . . . . . . . . . . . 11 3.2.3. Sample LFB Class Application . . . . . . . . . . . . . 11
3.3. Document Structure . . . . . . . . . . . . . . . . . . . . 12 3.3. Document Structure . . . . . . . . . . . . . . . . . . . . 12
4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. MetaData . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2. Compound struct . . . . . . . . . . . . . . . . . . . 15
4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 15 4.1.3. Compound array . . . . . . . . . . . . . . . . . . . . 15
5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 36 4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 36 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 36 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 17
5.1.1.1. Data Handling . . . . . . . . . . . . . . . . . . 36 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 38
5.1.1.2. Components . . . . . . . . . . . . . . . . . . . . 37 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 38
5.1.1.3. Capabilities . . . . . . . . . . . . . . . . . . . 38 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 38
5.1.1.4. Events . . . . . . . . . . . . . . . . . . . . . . 38 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . . 40
5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . . 38 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 42
5.1.2.1. Data Handling . . . . . . . . . . . . . . . . . . 38 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . . 44
5.1.2.2. Components . . . . . . . . . . . . . . . . . . . . 39 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 46
5.1.2.3. Capabilities . . . . . . . . . . . . . . . . . . . 40 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 47
5.1.2.4. Events . . . . . . . . . . . . . . . . . . . . . . 40 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 47
5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 40 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 49
5.1.4. EtherEncapsulator . . . . . . . . . . . . . . . . . . 42 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . . 51
5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 45
5.1.5.1. Data Handling . . . . . . . . . . . . . . . . . . 45
5.1.5.2. Components . . . . . . . . . . . . . . . . . . . . 45
5.1.5.3. Capabilities . . . . . . . . . . . . . . . . . . . 46
5.1.5.4. Events . . . . . . . . . . . . . . . . . . . . . . 46
5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 46
5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 46
5.2.1.1. Data Handling . . . . . . . . . . . . . . . . . . 46
5.2.1.2. Components . . . . . . . . . . . . . . . . . . . . 48
5.2.1.3. Capabilities . . . . . . . . . . . . . . . . . . . 48
5.2.1.4. Events . . . . . . . . . . . . . . . . . . . . . . 48
5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 48
5.2.2.1. Data Handling . . . . . . . . . . . . . . . . . . 48
5.2.2.2. Components . . . . . . . . . . . . . . . . . . . . 50
5.2.2.3. Capabilities . . . . . . . . . . . . . . . . . . . 50
5.2.2.4. Events . . . . . . . . . . . . . . . . . . . . . . 50
5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . . 50
5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . . 51 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . . 51
5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 52 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 53
5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . . 54 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . . 55
5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 54 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 57
5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 54 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 58
5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . . 54 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . . 59
5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 55 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 59
5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . . 55 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . . 60
5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 56 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 60
5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . . 56 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . . 61
6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 58 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 64
7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 80 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 86
7.1. IP Forwarding . . . . . . . . . . . . . . . . . . . . . . 80 7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 86
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . . 87
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 82 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 90
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 91
11. Security Considerations . . . . . . . . . . . . . . . . . . . 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 92
12.1. Normative References . . . . . . . . . . . . . . . . . . . 85 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 94
12.2. Informative References . . . . . . . . . . . . . . . . . . 85 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 95
11. Security Considerations . . . . . . . . . . . . . . . . . . . 97
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 98
12.1. Normative References . . . . . . . . . . . . . . . . . . . 98
12.2. Informative References . . . . . . . . . . . . . . . . . . 98
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Definitions 2. Definitions
skipping to change at page 10, line 43 skipping to change at page 10, line 43
IPv6UcastLPM (section 5.3.4) IPv6UcastLPM (section 5.3.4)
IPv6NextHop (section 5.3.4) IPv6NextHop (section 5.3.4)
(4) A group of LFBs are defined to abstract the process for redirect (4) A group of LFBs are defined to abstract the process for redirect
operation, i.e., data packet transmission between CE and FEs. operation, i.e., data packet transmission between CE and FEs.
The following LFBs are defined for redirect processing: The following LFBs are defined for redirect processing:
RedirectIn (section 5.5.1) RedirectIn (section 5.4.1)
RedirectOut (section 5.5.2) RedirectOut (section 5.4.2)
(5) A group of LFBs are defined for abstracting some general purpose (5) A group of LFBs are defined for abstracting some general purpose
packet processing. These processing processes are usually general to packet processing. These processing processes are usually general to
many processing locations in an FE LFB topology. many processing locations in an FE LFB topology.
The following LFBs are defined for redirect processing: The following LFBs are defined for redirect processing:
BasicMetadataDispatch (section 5.6.1) BasicMetadataDispatch (section 5.5.1)
GenericScheduler (section 5.6.2) GenericScheduler (section 5.5.2)
3.2.3. Sample LFB Class Application 3.2.3. Sample LFB Class Application
Although section 7 will present use cases for LFBs defined in this Although section 7 will present use cases for LFBs defined in this
document, this section shows a sample LFB class application in document, this section shows a sample LFB class application in
advance so that readers can get a quick overlook of the LFB classes advance so that readers can get a quick overlook of the LFB classes
with the usage.
Figure 1 shows the typical LFB processing path for an IPv4 unicast Figure 1 shows the typical LFB processing path for an IPv4 unicast
forwarding case with Ethernet media interfaces. To focus on the IP forwarding case with Ethernet media interfaces. To focus on the IP
forwarding function, some inputs or outputs of LFBs in the figure forwarding function, some inputs or outputs of LFBs in the figure
that are not related to the function are missed. Section 7.1 will that are not related to the function are ignored. Section 7.1 will
describe the LFB topology in more details. describe the figure in more details.
+-----+ +------+ +-----+ +------+
| | | | | | | |
| |<---------------|Ether |<----------------------------+ | |<---------------|Ether |<----------------------------+
| | |MACOut| | | | |MACOut| |
| | | | | | | | | |
|Ether| +------+ | |Ether| +------+ |
|PHY | | |PHY | |
|Cop | +---+ | |Cop | +---+ |
|#1 | +-----+ | |----->IPv6 Packets | |#1 | +-----+ | |----->IPv6 Packets |
| | | | | | +----+ | | | | | | | |
| | |Ether| | | | | | | | |Ether| | | IPv4 Packets |
| |->|MACIn|-->| |IPv4| | | | |->|MACIn|-->| |-+ +----+ |
+-----+ | | | |-+->| | +---+ | +-----+ | | | | | | |---> Multicast Packets |
+-----+ +--+ | | |unicast +-----+ | | | +-----+ +---+ | | | +-----+ +---+ |
Ether | | |------->| | | | | Ether +->| |------->| | | | |
. Classifier| | |packet |IPv4 | | | | . Classifier| | |Unicast |IPv4 | | | |
. | | | |Ucast|->| |--+ | . | | |Packets |Ucast|->| |--+ |
. | | | |LPM | | | | | . | +----+ |LPM | | | | |
+---+ | +----+ +-----+ | | | | +---+ | IPv4 +-----+ +---+ | |
+-----+ | | | IPv4 +---+ | | +-----+ | | | Validator IPv4 | |
| | | | | Validator IPv4 | | | | | | | NextHop| |
+-----+ |Ether| | |-+ NextHop | | +-----+ |Ether| | |-+ IPv4 Packets | |
| |->|MACIn|-->| |IPv4 | | | |->|MACIn|-->| | | |
| | | | | |----->IPv6 Packets | | | | | | | |----->IPv6 Packets | |
|Ether| +-----+ +---+ +----+ | | |Ether| +-----+ +---+ | |
|PHY | Ether | | | | |PHY | Ether +----+ | |
|Cop | Classifier | | +-------+ | | |Cop | Classifier | | +-------+ | |
|#n | | | | | | | |#n | +------+ | | |Ether | | |
| | +------+ | |<--| Ether |<-+ | | | | | | |<--|Encap |<-+ |
| | | |<------| | | Encap | | | | | |<------| | | | |
| |<---------------|Ether | ...| | +-------+ | | |<---------------|Ether | ...| | +-------+ |
| | |MACOut| +---| | | | | |MACOut| +---| | |
| | | | | +----+ | | | | | | +----+ |
+-----+ +------+ | BasicMetadataDispatch | +-----+ +------+ | BasicMetadataDispatch |
+-------------------------+ +-------------------------+
Figure 1: AIPv4 Forwarding Case Figure 1: LFB use case for IPv4 forwarding
3.3. Document Structure 3.3. Document Structure
Base type definitions, including data types, packet frame types, and Base type definitions, including data types, packet frame types, and
etadata types are presented in advance for definitions of various LFB etadata types are presented in advance for definitions of various LFB
classes. Section 4 (Base Types Section) provide a description on the classes. Section 4 (Base Types Section) provide a description on the
base types used by this LFB library. In order for an extensive use base types used by this LFB library. In order for an extensive use
of these base types for other LFB class definitions, the base type of these base types for other LFB class definitions, the base type
definitions are provided by an xml file in a way as a library which definitions are provided by an xml file in a way as a library which
is separate from the LFB definition library. is separate from the LFB definition library.
skipping to change at page 14, line 7 skipping to change at page 14, line 7
defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB
Definitions Section) provide the complete XML definitions of the base Definitions Section) provide the complete XML definitions of the base
LFB classes library.. LFB classes library..
Section 7 provides several use cases on how some typical router Section 7 provides several use cases on how some typical router
functions can be implemented using the base LFB library defined in functions can be implemented using the base LFB library defined in
this document. this document.
4. Base Types 4. Base Types
TThe FE model [RFC5812] has specified the following data types as TThe FE model [RFC5812] has specified predefined (built-in) atomic
predefined (built-in) atomic data-types: data-types as below:
char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N],
string, byte[N], boolean, octetstring[N], float16, float32, float64. string, byte[N], boolean, octetstring[N], float16, float32, float64.
Based on these atomic data types and with the use of type definition Based on the atomic data types and with the use of type definition
elements in the FE model XML schema, new data types, packet frame elements in the FE model XML schema, new data types, packet frame
types, and metadata types can further be defined. types, and metadata types can be defined.
To define a base LFB library for typical router functions, a base To define a base LFB library for typical router functions, a set of
data types, frame types, and metadata types MUST be defined. This base data types, frame types, and metadata types should be defined.
section provides a description of these types and detailed XML This section provides a brief description of the base types and a
definitions for the base types. full XML definition of them as well.
In order for extensive use of the base type definitions for LFB The base type XML definitions are provided with a separate XML
definitions other than this base LFB library, the base type library file named "BaseTypeLibrary". Users can refer to this
definitions are provided with a separate xml library file labeled library by the statement:
with "BaseTypeLibrary". Users can refer to this library by the
statement:
<load library="BaseTypeLibrary", location="..."/> <load library="BaseTypeLibrary", location="..."/>
4.1. Data 4.1. Data Types
The following data types are currently defined and put in the base Data types defined in the base type library are categorized by types
type library: of atomic, compound struct, and compound array.
(TBD) 4.1.1. Atomic
4.2. Frame The following data types are defined as atomic data types and put in
the base type library:
Data Type Name Brief Description
-------------- -----------------
IPv4Addr IPv4 address
IPv6Addr IPv6 address
IEEEMAC IEEE mac address.
LANSpeedType Network speed values
DuplexType Duplex types
PortStatusValues The possible values of port status, used for
both administrative and operative status.
SchdDisciplineType Scheduling discipline type.
4.1.2. Compound struct
The following compound struct types are defined in the base type
library:
Data Type Name Brief Description
-------------- -----------------
EtherDispatchEntryType Entry type for Ethernet dispatch table.
VlanInputTableEntryType Entry type for VLAN input table.
EncapTableEntryType Entry type for Ethernet encapsulation table.
MACInStatsType Statistics type for EtherMACIn LFB.
MACOutStatsType Statistics type for EtherMACOut LFB.
EtherClassifyStatsType Entry type for statistics table in
EtherClassifier LFB.
IPv4PrefixInfoType Entry type for IPv4 prefix table.
IPv6PrefixInfoType Entry type for IPv6 prefix table
IPv4NextHopInfoType Entry type for IPv4 next hop table.
IPv6NextHopInfoType Entry type for IPv6 next hop table.
IPv4ValidatorStatsType Statistics type in IPv4validator LFB.
IPv6ValidatorStatsType Statistics type in IPv6validator LFB.
IPv4UcastLPMStatsType Statistics type in IPv4Unicast LFB.
IPv6UcastLPMStatsType Statistics type in IPv6Unicast LFB.
QueueDepthType Entry type for queue depth table.
MetadataDispatchType Entry type for metadata dispatch table.
4.1.3. Compound array
Compound array types are mostly created based on compound struct
types for LFB table components. The following compound array types
are defined in this base type library:
Data Type Name Brief Description
-------------- -----------------
EtherClassifyStatsTableType Type for Ethernet classifier statistics
information table
EtherDispatchTableType Type for Ethernet dispatch table.
VlanInputTableType Type for VLAN input table.
EncapTableType Type for Ethernet encapsulation table.
IPv4PrefixTableType Type for IPv4 prefix table.
IPv6PrefixTableType Type for IPv6 prefix table.
IPv4NextHopTableType Type for IPv4 next hop table.
IPv6NextHopTableType Type for IPv6 next hop table.
MetadataDispatchTableType Type for Metadata dispatch table.
QueueDepthTableType Type for Queue depth table.
4.2. Frame Types
According to FE model [RFC5812], frame types are used in LFB According to FE model [RFC5812], frame types are used in LFB
definitions to define the types of frames the LFB expects at its definitions to define the types of frames the LFB expects at its
input port(s) and emits at its output port(s). The <frameDef> input port and emits at its output port. The <frameDef> element in
element in the FE model is used to define a new frame type. the FE model is used to define a new frame type.
The following frame types are currently defined and put in the base The following frame types are defined in the base type library:
type library as base frame types for the LFB library:
(TBD) Frame Name Brief Description
-------------- ----------------
EthernetII An Ethernet II frame
ARP An ARP packet
IPv4 An IPv4 packet
IPv6 An IPv6 packet
IPv4Unicast An IPv4 unicast packet
IPv4Multicast An IPv4 multicast packet
IPv6Unicast An IPv6 unicast packet
IPv6Multicast An IPv6 multicast packet
Arbitrary Any types of packet frames
4.3. MetaData 4.3. MetaData Types
LFB Metadata is used to communicate per-packet state from one LFB to LFB Metadata is used to communicate per-packet state from one LFB to
another. The <metadataDef> element in the FE model is used to define another. The <metadataDef> element in the FE model is used to define
a new metadata type. a new metadata type.
The following metadata types are currently defined and put in the The following metadata types are currently defined in the base type
base type library as base metadata types for the LFB library library.
definitions:
(TBD) Metadata Name Metadata ID Brief Description
------------ ---------- -------------
PHYPortID 1 The physical port ID that the packet is
inputted.
SrcMAC 2 Source MAC address of the packet.
DstMAC 3 Destination MAC address of the packet.
LogicalPortID 4 ID of a logical port for the packet.
EtherType 5 Indicating the Ethernet type of the
Ethernet packet.
VlanID 6 The VLAN ID of the Ethernet packet.
VlanPriority 7 The priority of the Ethernet packet.
NexthopIPv4Addr 8 Nexthop IPv4 address the packet is sent to.
NexthopIPv6Addr 9 Nexthop IPv6 address the packet is sent to.
HopSelector 10 An index the packet can use to look up a
nexthop table for next hop information of
the packet.
ExceptionID 11 Indicating exception type of the packet
which is exceptional for some processing.
ValidateErrorID 12 Indicating error type of the packet failed
some validation process.
L3PortID 13 ID of L3 port.
RedirectIndex 14 A metadata CE sends to RedirectIn LFB for
the associated packet to select output
port in the LFB group output "PktsOut".
MediaEncapInfoIndex 15 An index the packet uses to look up a media
encapsulation table to select its
encapsulation media as well as followed
encapsulation LFB.
4.4. XML for Base Type Library 4.4. XML for Base Type Library
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseTypeLibrary"> provides="BaseTypeLibrary">
<frameDefs> <frameDefs>
<frameDef> <frameDef>
<name>EthernetAll</name> <name>EthernetAll</name>
<synopsis>An kinds of Ethernet frame</synopsis> <synopsis>All kinds of Ethernet frame</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>EthernetII</name> <name>EthernetII</name>
<synopsis>An Ethernet II frame</synopsis> <synopsis>An Ethernet II frame</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>ARP</name> <name>ARP</name>
<synopsis>an arp packet</synopsis> <synopsis>An arp packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv4</name> <name>IPv4</name>
<synopsis>An IPv4 packet</synopsis> <synopsis>An IPv4 packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv6</name> <name>IPv6</name>
<synopsis>An IPv6 packet</synopsis> <synopsis>An IPv6 packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
skipping to change at page 16, line 14 skipping to change at page 18, line 32
<frameDef> <frameDef>
<name>IPv6Unicast</name> <name>IPv6Unicast</name>
<synopsis>An IPv6 unicast packet</synopsis> <synopsis>An IPv6 unicast packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv6Multicast</name> <name>IPv6Multicast</name>
<synopsis>An IPv6 multicast packet</synopsis> <synopsis>An IPv6 multicast packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>Arbitrary</name> <name>Arbitrary</name>
<synopsis>Any kinds of frames</synopsis> <synopsis>Any types of packet frames</synopsis>
</frameDef> </frameDef>
</frameDefs> </frameDefs>
<dataTypeDefs> <dataTypeDefs>
<dataTypeDef> <dataTypeDef>
<name>IPv4Addr</name> <name>IPv4Addr</name>
<synopsis>IPv4 address</synopsis> <synopsis>IPv4 address</synopsis>
<typeRef>byte[4]</typeRef> <typeRef>byte[4]</typeRef>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6Addr</name> <name>IPv6Addr</name>
<synopsis>IPv6 address</synopsis> <synopsis>IPv6 address</synopsis>
<typeRef>byte[16]</typeRef> <typeRef>byte[16]</typeRef>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IEEEMAC</name> <name>IEEEMAC</name>
<synopsis>IEEE mac.</synopsis> <synopsis>IEEE mac address.</synopsis>
<typeRef>byte[6]</typeRef> <typeRef>byte[6]</typeRef>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>LANSpeedType</name> <name>LANSpeedType</name>
<!-- <name>NetSpeedType</name> -->
<synopsis>Network speed values</synopsis> <synopsis>Network speed values</synopsis>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="0x00000001"> <specialValue value="0x00000001">
<name>LAN_SPEED_10M</name> <name>LAN_SPEED_10M</name>
<synopsis>10M Ethernet</synopsis> <synopsis>10M Ethernet</synopsis>
</specialValue> </specialValue>
<specialValue value="0x00000002"> <specialValue value="0x00000002">
<name>LAN_SPEED_100M</name> <name>LAN_SPEED_100M</name>
skipping to change at page 17, line 17 skipping to change at page 19, line 33
</specialValue> </specialValue>
<specialValue value="0x00000005"> <specialValue value="0x00000005">
<name>LAN_SPEED_AUTO</name> <name>LAN_SPEED_AUTO</name>
<synopsis>LAN speed auto</synopsis> <synopsis>LAN speed auto</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>DuplexType</name> <name>DuplexType</name>
<!-- <typeRef>IEEENegotiationType</typeRef> -->
<synopsis>Duplex types</synopsis> <synopsis>Duplex types</synopsis>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="0x00000001"> <specialValue value="0x00000001">
<name>Auto</name> <name>Auto</name>
<synopsis>Auto negotitation.</synopsis> <synopsis>Auto negotitation.</synopsis>
</specialValue> </specialValue>
<specialValue value="0x00000002"> <specialValue value="0x00000002">
<name>Half-duplex</name> <name>Half-duplex</name>
skipping to change at page 17, line 37 skipping to change at page 20, line 4
<name>Half-duplex</name> <name>Half-duplex</name>
<synopsis>port negotitation half duplex</synopsis> <synopsis>port negotitation half duplex</synopsis>
</specialValue> </specialValue>
<specialValue value="0x00000003"> <specialValue value="0x00000003">
<name>Full-duplex</name> <name>Full-duplex</name>
<synopsis>port negotitation full duplex</synopsis> <synopsis>port negotitation full duplex</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
<!-- XXX: This is very IEEE specific --> <!-- XXX: This is very IEEE specific -->
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>PortStatusValues</name> <name>PortStatusValues</name>
<synopsis>The possible values of status. Used for both <synopsis>The possible values of port status, used for both
administrative and operation status.</synopsis> administrative and operative status.</synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>Disabled </name> <name>Disabled </name>
<synopsis>the port is operatively disabled.</synopsis> <synopsis>the port is operatively disabled.</synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name>UP</name> <name>UP</name>
<synopsis>the port is up.</synopsis> <synopsis>the port is up.</synopsis>
skipping to change at page 18, line 15 skipping to change at page 20, line 30
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>Down</name> <name>Down</name>
<synopsis>The port is down.</synopsis> <synopsis>The port is down.</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MACInStatsType</name> <name>MACInStatsType</name>
<synopsis>The content of statistic for EtherMACIn.</synopsis> <synopsis>Statistics type in EtherMACIn.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>NumPacketsReceived</name> <name>NumPacketsReceived</name>
<synopsis>The number of packets received.</synopsis> <synopsis>The number of packets received.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>NumPacketsDropped</name> <name>NumPacketsDropped</name>
<synopsis>The number of packets dropped.</synopsis> <synopsis>The number of packets dropped.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MACOutStatsType</name> <name>MACOutStatsType</name>
<synopsis>The content of statistic for EtherMACOut.</synopsis> <synopsis>Statistics type in EtherMACOut.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>NumPacketsTransmitted</name> <name>NumPacketsTransmitted</name>
<synopsis>The number of packets transmitted.</synopsis> <synopsis>The number of packets transmitted.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>NumPacketsDropped</name> <name>NumPacketsDropped</name>
<synopsis>The number of packets dropped.</synopsis> <synopsis>The number of packets dropped.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherDispatchEntryType</name> <name>EtherDispatchEntryType</name>
<synopsis>the type of EtherDispatch table entry.</synopsis> <synopsis>Entry type for Ethernet dispatch table.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>LogicalPortID</name> <name>LogicalPortID</name>
<synopsis>Logical port ID.</synopsis> <synopsis>Logical port ID.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>EtherType</name> <name>EtherType</name>
<synopsis>The EtherType value in the Ether head. <synopsis>The EtherType value in the Ether head.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>OutputIndex</name> <name>LFBOutputSelectIndex</name>
<synopsis>Group output port index.</synopsis> <synopsis>LFB Group output port index to select
downstream LFB port. Some possibilities of downstream
LFB instances are:
a) IPv4Validator
b) IPv6Validator
c) RedirectOut
d) etc
Note: LFBOutputSelectIndex is the FromPortIndex for
the port group "ClassifyOut" in the table LFBTopology
(of FEObject LFB) as defined for the EtherClassifier
LFB.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherDispatchTableType</name> <name>EtherDispatchTableType</name>
<synopsis>the type of EtherDispatch table.</synopsis> <synopsis>Type for Ethernet dispatch table.</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>EtherDispatchEntryType</typeRef> <typeRef>EtherDispatchEntryType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>VlanInputTableEntryType</name> <name>VlanInputTableEntryType</name>
<synopsis>Vlan input table entry type.</synopsis> <synopsis>Entry type for VLAN input table.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IncomingPortID</name> <name>IncomingPortID</name>
<synopsis>The incoming port ID.</synopsis> <synopsis>The incoming port ID.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>VlanID</name> <name>VlanID</name>
<synopsis>Vlan ID.</synopsis> <synopsis>Vlan ID.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>LogicalPortID</name> <name>LogicalPortID</name>
<synopsis>logical port ID.</synopsis> <synopsis>logical port ID.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>VlanInputTableType</name> <name>VlanInputTableType</name>
<synopsis>Vlan input table type.</synopsis> <synopsis>Type for VLAN input table.</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>VlanInputTableEntryType</typeRef> <typeRef>VlanInputTableEntryType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherClassifyStatsType</name> <name>EtherClassifyStatsType</name>
<synopsis>Ether classify statistic information.</synopsis> <synopsis>Entry type for statistics table in EtherClassifier
LFB.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>EtherType</name> <name>EtherType</name>
<synopsis>The EtherType value</synopsis> <synopsis>The EtherType value</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>PacketsNum</name> <name>PacketsNum</name>
<synopsis>Packets number</synopsis> <synopsis>Packets number</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherClassifyStatsTableType</name> <name>EtherClassifyStatsTableType</name>
<synopsis>Ether classify statistic information <synopsis>Type for Ethernet classifier statistics
table type.</synopsis> information table.</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>EtherClassifyStatsType</typeRef> <typeRef>EtherClassifyStatsType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4ValidatorStatisticsType</name> <name>IPv4ValidatorStatsType</name>
<synopsis>Statistics type in IPv4validator.</synopsis> <synopsis>Statistics type in IPv4validator.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>badHeaderPkts</name> <name>badHeaderPkts</name>
<synopsis>Number of bad header packets.</synopsis> <synopsis>Number of bad header packets.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>badTotalLengthPkts</name> <name>badTotalLengthPkts</name>
<synopsis>Number of bad total length packets.</synopsis> <synopsis>Number of bad total length packets.</synopsis>
skipping to change at page 21, line 4 skipping to change at page 23, line 30
</component> </component>
<component componentID="3"> <component componentID="3">
<name>badTTLPkts</name> <name>badTTLPkts</name>
<synopsis>Number of bad TTL packets.</synopsis> <synopsis>Number of bad TTL packets.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>badChecksumPkts</name> <name>badChecksumPkts</name>
<synopsis>Number of bad checksum packets.</synopsis> <synopsis>Number of bad checksum packets.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6ValidatorStatisticsType</name> <name>IPv6ValidatorStatsType</name>
<synopsis>Statistics type in IPv6validator.</synopsis> <synopsis>Statistics type in IPv6validator.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>badHeaderPkts</name> <name>badHeaderPkts</name>
<synopsis>Number of bad header packets.</synopsis> <synopsis>Number of bad header packets.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>badTotalLengthPkts</name> <name>badTotalLengthPkts</name>
<synopsis>Number of bad total length packets.</synopsis> <synopsis>Number of bad total length packets.</synopsis>
skipping to change at page 21, line 27 skipping to change at page 24, line 4
<component componentID="2"> <component componentID="2">
<name>badTotalLengthPkts</name> <name>badTotalLengthPkts</name>
<synopsis>Number of bad total length packets.</synopsis> <synopsis>Number of bad total length packets.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>badHopLimitPkts</name> <name>badHopLimitPkts</name>
<synopsis>Number of bad Hop limit packets.</synopsis> <synopsis>Number of bad Hop limit packets.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4PrefixInfoType</name> <name>IPv4PrefixInfoType</name>
<synopsis>IPv4 Prefix information,entry type for <synopsis>Entry type for IPv4 prefix table.</synopsis>
IPv4 prefix table.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IPv4Address</name> <name>IPv4Address</name>
<synopsis>An IPv4 Address</synopsis> <synopsis>An IPv4 Address</synopsis>
<typeRef>IPv4Addr</typeRef> <typeRef>IPv4Addr</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>Prefixlen</name> <name>Prefixlen</name>
<synopsis>The prefix length</synopsis> <synopsis>The prefix length</synopsis>
<atomic> <atomic>
skipping to change at page 22, line 27 skipping to change at page 25, line 4
<specialValue value="true"> <specialValue value="true">
<name>True</name> <name>True</name>
<synopsis>This route has multiple nexthops. <synopsis>This route has multiple nexthops.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</component> </component>
<component componentID="5"> <component componentID="5">
<name>DefaultRouteFlag</name> <name>DefaultRouteFlag</name>
<synopsis>A Default Route Flag for supporting loose RPF. <synopsis>A default route flag.</synopsis>
</synopsis>
<atomic> <atomic>
<baseType>boolean</baseType> <baseType>boolean</baseType>
<specialValues> <specialValues>
<specialValue value="false"> <specialValue value="false">
<name>False</name> <name>False</name>
<synopsis>This is not a default route. <synopsis>This is not a default route.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="true"> <specialValue value="true">
<name>True</name> <name>True</name>
<synopsis>This route is a default route. for <synopsis>This route is a default route.
supporting the loose RPF.</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4PrefixTableType</name> <name>IPv4PrefixTableType</name>
<synopsis>IPv4 prefix table type.</synopsis> <synopsis>Type for IPv4 prefix table.</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>IPv4PrefixInfoType</typeRef> <typeRef>IPv4PrefixInfoType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4UcastLPMStatsType</name> <name>IPv4UcastLPMStatsType</name>
<synopsis>Statistics type in IPv4Unicast.</synopsis> <synopsis>Statistics type in IPv4Unicast LFB.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>InRcvdPkts</name> <name>InRcvdPkts</name>
<synopsis>The total number of input packets <synopsis>The total number of input packets received.
received</synopsis> </synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>FwdPkts</name> <name>FwdPkts</name>
<synopsis>IPv4 packets forwarded by this LFB</synopsis> <synopsis>IPv4 packets forwarded by this LFB</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>NoRoutePkts</name> <name>NoRoutePkts</name>
<synopsis>The number of IP datagrams discarded because <synopsis>The number of IP datagrams discarded because
skipping to change at page 23, line 29 skipping to change at page 26, line 4
<synopsis>IPv4 packets forwarded by this LFB</synopsis> <synopsis>IPv4 packets forwarded by this LFB</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>NoRoutePkts</name> <name>NoRoutePkts</name>
<synopsis>The number of IP datagrams discarded because <synopsis>The number of IP datagrams discarded because
no route could be found.</synopsis> no route could be found.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6PrefixInfoType</name> <name>IPv6PrefixInfoType</name>
<synopsis>IPv6 Prefix information,entry type for <synopsis>Entry type for IPv6 prefix table.</synopsis>
IPv6 prefix table</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IPv6Address</name> <name>IPv6Address</name>
<synopsis>An IPv6 Address</synopsis> <synopsis>An IPv6 Address</synopsis>
<typeRef>IPv6Addr</typeRef> <typeRef>IPv6Addr</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>Prefixlen</name> <name>Prefixlen</name>
<synopsis>The prefix length</synopsis> <synopsis>The prefix length</synopsis>
<atomic> <atomic>
skipping to change at page 24, line 49 skipping to change at page 27, line 24
<synopsis>This route is a default route. <synopsis>This route is a default route.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6PrefixTableType</name> <name>IPv6PrefixTableType</name>
<synopsis>IPv6 prefix table type.</synopsis> <synopsis>Type for IPv6 prefix table.</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>IPv6PrefixInfoType</typeRef> <typeRef>IPv6PrefixInfoType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6UcastLPMStatsType</name> <name>IPv6UcastLPMStatsType</name>
<synopsis>Statistics type in IPv6Unicast.</synopsis> <synopsis>Statistics type in IPv6Unicast LFB.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>InRcvdPkts</name> <name>InRcvdPkts</name>
<synopsis>The total number of input packets <synopsis>The total number of input packets
received</synopsis> received</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>FwdPkts</name> <name>FwdPkts</name>
<synopsis>IPv6 packets forwarded by this LFB</synopsis> <synopsis>IPv6 packets forwarded by this LFB</synopsis>
skipping to change at page 25, line 32 skipping to change at page 28, line 6
<component componentID="3"> <component componentID="3">
<name>NoRoutePkts</name> <name>NoRoutePkts</name>
<synopsis>The number of IP datagrams discarded because <synopsis>The number of IP datagrams discarded because
no route could be found.</synopsis> no route could be found.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4NextHopInfoType</name> <name>IPv4NextHopInfoType</name>
<synopsis>IPv4 next hop information. Entry type for the <synopsis>Entry type for IPv4 next hop table.</synopsis>
IPv4 next hop table.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>L3PortID</name> <name>L3PortID</name>
<synopsis>The ID of the Logical/physical Output Port <synopsis>The ID of the Logical/physical Output Port
that we pass onto the neighboring LFB instance. This that we pass onto the neighboring LFB instance. This
ID indicates what port to the neighbor is as defined ID indicates what port to the neighbor is as defined
by L3.</synopsis> by L3.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
skipping to change at page 26, line 19 skipping to change at page 28, line 41
instance. This index is used to lookup a table instance. This index is used to lookup a table
(typically media encapsulatation related) further (typically media encapsulatation related) further
downstream.</synopsis> downstream.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="5"> <component componentID="5">
<name>LFBOutputSelectIndex</name> <name>LFBOutputSelectIndex</name>
<synopsis>LFB Group output port index to select <synopsis>LFB Group output port index to select
downstream LFB port. Some possibilities of downstream downstream LFB port. Some possibilities of downstream
LFB instances are: LFB instances are:
a) EtherEncapsulator a) EtherEncap
b) Other type of media LFB b) Other type of media LFB
c) A metadata Dispatcher c) A metadata Dispatcher
d) A redirect LFB d) A redirect LFB
e) etc e) etc
Note: LFBOutputSelectIndex is the FromPortIndex for Note: LFBOutputSelectIndex is the FromPortIndex for
the port group "successout" in the table LFBTopology the port group "SuccessOut" in the table LFBTopology
(of FEObject LFB) as defined for the NH LFB. (of FEObject LFB) as defined for the IPv4NextHop LFB.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4NextHopTableType</name> <name>IPv4NextHopTableType</name>
<synopsis>IPv4 next hop table type</synopsis> <synopsis>Type for IPv4 next hop table.</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>IPv4NextHopInfoType</typeRef> <typeRef>IPv4NextHopInfoType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6NextHopInfoType</name> <name>IPv6NextHopInfoType</name>
<synopsis>IPv6 next hop information. Entry type for the <synopsis>Entry type for IPv6 next hop table.</synopsis>
IPv6NextHopTable.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>L3PortID</name> <name>L3PortID</name>
<synopsis>The ID of the Logical/physical Output Port <synopsis>The ID of the Logical/physical Output Port
that we pass onto the neighboring LFB instance. This that we pass onto the neighboring LFB instance. This
ID indicates what port to the neighbor is as defined ID indicates what port to the neighbor is as defined
by L3.</synopsis> by L3.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
skipping to change at page 27, line 29 skipping to change at page 29, line 51
instance. This index is used to lookup a table instance. This index is used to lookup a table
(typically media encapsulatation related) further (typically media encapsulatation related) further
downstream.</synopsis> downstream.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="5"> <component componentID="5">
<name>LFBOutputSelectIndex</name> <name>LFBOutputSelectIndex</name>
<synopsis>LFB Group output port index to select <synopsis>LFB Group output port index to select
downstream LFB port. Some possibilities of downstream downstream LFB port. Some possibilities of downstream
LFB instances are: LFB instances are:
a) EtherEncapsulator a) EtherEncap
b) Other type of media LFB b) Other type of media LFB
c) A metadata Dispatcher c) A metadata Dispatcher
d) A redirect LFB d) A redirect LFB
e) etc e) etc
Note: LFBOutputSelectIndex is the FromPortIndex for Note: LFBOutputSelectIndex is the FromPortIndex for
the port group "successout" in the table LFBTopology the port group "SuccessOut" in the table LFBTopology
(of FEObject LFB) as defined for the NH LFB. (of FEObject LFB) as defined for the IPv6NextHop LFB.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6NextHopTableType</name> <name>IPv6NextHopTableType</name>
<synopsis>IPv6 next hop table type</synopsis> <synopsis>Type for IPv6 next hop table.</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>IPv6NextHopInfoType</typeRef> <typeRef>IPv6NextHopInfoType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EncapTableEntryType</name> <name>EncapTableEntryType</name>
<synopsis>Ethernet encapsulation table entry type.</synopsis> <synopsis>Entry type for Ethernet encapsulation table.
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>DstMac</name> <name>DstMac</name>
<synopsis>Ethernet Mac of the Neighbor</synopsis> <synopsis>Ethernet Mac of the Neighbor</synopsis>
<typeRef>IEEEMAC</typeRef> <typeRef>IEEEMAC</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>SrcMac</name> <name>SrcMac</name>
<synopsis>Source MAC used in encapsulation</synopsis> <synopsis>Source MAC used in encapsulation</synopsis>
<typeRef>IEEEMAC</typeRef> <typeRef>IEEEMAC</typeRef>
skipping to change at page 28, line 29 skipping to change at page 30, line 51
</component> </component>
<component componentID="4"> <component componentID="4">
<name>L2PortID</name> <name>L2PortID</name>
<synopsis>Output logical L2 port ID.</synopsis> <synopsis>Output logical L2 port ID.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EncapTableType</name> <name>EncapTableType</name>
<synopsis>Ethernet encapsulation table type</synopsis> <synopsis>Type for Ethernet encapsulation table.</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>EncapTableEntryType</typeRef> <typeRef>EncapTableEntryType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MetadataDispatchType</name> <name>MetadataDispatchType</name>
<synopsis>The entry type for Metadata dispatch table. <synopsis>Entry type for metadata dispatch table.</synopsis>
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>MetadataID</name> <name>MetadataID</name>
<synopsis>metadata ID</synopsis> <synopsis>metadata ID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>MetadataValue</name> <name>MetadataValue</name>
<synopsis>metadata value.</synopsis> <synopsis>metadata value.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>OutputIndex</name> <name>OutputIndex</name>
<synopsis>group output port index.</synopsis> <synopsis>group output port index.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MetadataDispatchTableType</name> <name>MetadataDispatchTableType</name>
<synopsis> Metadata dispatch table type.</synopsis> <synopsis>Type for Metadata dispatch table.</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>MetadataDispatchType</typeRef> <typeRef>MetadataDispatchType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>SchdDisciplineType</name> <name>SchdDisciplineType</name>
<synopsis>scheduling discipline type.</synopsis> <synopsis>Scheduling discipline type.</synopsis>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="1"> <specialValue value="1">
<name>FIFO</name> <name>FIFO</name>
<synopsis>First In First Out scheduler.</synopsis> <synopsis>First In First Out scheduler.</synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>RR</name> <name>RR</name>
<synopsis>Round Robin.</synopsis> <synopsis>Round Robin.</synopsis>
skipping to change at page 29, line 31 skipping to change at page 32, line 4
<specialValue value="1"> <specialValue value="1">
<name>FIFO</name> <name>FIFO</name>
<synopsis>First In First Out scheduler.</synopsis> <synopsis>First In First Out scheduler.</synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>RR</name> <name>RR</name>
<synopsis>Round Robin.</synopsis> <synopsis>Round Robin.</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>QueueDepthType</name> <name>QueueDepthType</name>
<synopsis>the entry type for queue depth <synopsis>Entry type for queue depth table.</synopsis>
table.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>QueueID</name> <name>QueueID</name>
<synopsis>Queue ID</synopsis> <synopsis>Queue ID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>QueueDepthInPackets</name> <name>QueueDepthInPackets</name>
<synopsis>the Queue Depth when the depth units <synopsis>the Queue Depth when the depth units
are packets.</synopsis> are packets.</synopsis>
skipping to change at page 30, line 10 skipping to change at page 32, line 31
<component componentID="3"> <component componentID="3">
<name>QueueDepthInBytes</name> <name>QueueDepthInBytes</name>
<synopsis>the Queue Depth when the depth units <synopsis>the Queue Depth when the depth units
are bytes.</synopsis> are bytes.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>QueueDepthTableType</name> <name>QueueDepthTableType</name>
<synopsis>the Depth of Queue table type.</synopsis> <synopsis>Type for Queue depth table.</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>QueueDepthType</typeRef> <typeRef>QueueDepthType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
</dataTypeDefs> </dataTypeDefs>
<metadataDefs> <metadataDefs>
<metadataDef> <metadataDef>
<name>PHYPortID</name> <name>PHYPortID</name>
<synopsis>The physical port ID that a packet has entered. <synopsis>The physical port ID that a packet has entered.
</synopsis> </synopsis>
<metadataID>1</metadataID> <metadataID>1</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>SrcMAC</name> <name>SrcMAC</name>
<synopsis>Source MAC Address</synopsis> <synopsis>Source MAC address of the packet.</synopsis>
<metadataID>2</metadataID> <metadataID>2</metadataID>
<typeRef>IEEEMAC</typeRef> <typeRef>IEEEMAC</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>DstMAC</name> <name>DstMAC</name>
<synopsis>Destination MAC Address</synopsis> <synopsis>Destination MAC address of the packet.</synopsis>
<metadataID>3</metadataID> <metadataID>3</metadataID>
<typeRef>IEEEMAC</typeRef> <typeRef>IEEEMAC</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>LogicalPortID</name> <name>LogicalPortID</name>
<synopsis>ID of logical port.</synopsis> <synopsis>ID of a logical port for the packet.</synopsis>
<metadataID>4</metadataID> <metadataID>4</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>EtherType</name> <name>EtherType</name>
<synopsis>The value of EtherType.</synopsis> <synopsis>Indicating the Ethernet type of the Ethernet packet.
</synopsis>
<metadataID>5</metadataID> <metadataID>5</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>VlanID</name> <name>VlanID</name>
<synopsis>Vlan ID.</synopsis> <synopsis>The Vlan ID of the Ethernet packet.</synopsis>
<metadataID>6</metadataID> <metadataID>6</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>VlanPriority</name> <name>VlanPriority</name>
<synopsis>The priority of Vlan.</synopsis> <synopsis>The priority of the Ethernet packet.</synopsis>
<metadataID>7</metadataID> <metadataID>7</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>NexthopIPv4Addr</name> <name>NexthopIPv4Addr</name>
<synopsis>Nexthop IP address.</synopsis> <synopsis>Nexthop IPv4 address the packet is sent to.
</synopsis>
<metadataID>8</metadataID> <metadataID>8</metadataID>
<typeRef>IPv4Addr</typeRef> <typeRef>IPv4Addr</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>NexthopIPv6Addr</name> <name>NexthopIPv6Addr</name>
<synopsis>Nexthop IP address.</synopsis> <synopsis>Nexthop IPv6 address the packet is sent to.
</synopsis>
<metadataID>9</metadataID> <metadataID>9</metadataID>
<typeRef>IPv6Addr</typeRef> <typeRef>IPv6Addr</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>HopSelector</name> <name>HopSelector</name>
<synopsis>HopSelector is the nexthop ID which points to the <synopsis>An index the packet can use to look up a nexthop
nexthop table </synopsis> table for next hop information of the packet.</synopsis>
<metadataID>10</metadataID> <metadataID>10</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>ExceptionID</name> <name>ExceptionID</name>
<synopsis>Exception Types</synopsis> <synopsis>Indicating exception type of the packet which is
exceptional for some processing.</synopsis>
<metadataID>11</metadataID> <metadataID>11</metadataID>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>Other</name> <name>AnyUnrecognizedExceptionCase</name>
<synopsis>Any other exception.</synopsis> <synopsis>any unrecognized exception case.</synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name>BroadCastPacket</name> <name>BroadCastPacket</name>
<synopsis>Packet with destination address equal to <synopsis>Packet with destination address equal to
255.255.255.255</synopsis> 255.255.255.255</synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>BadTTL</name> <name>BadTTL</name>
<synopsis>The packet can't be forwarded as the TTL <synopsis>The packet can't be forwarded as the TTL
has expired.</synopsis> has expired.</synopsis>
skipping to change at page 33, line 14 skipping to change at page 35, line 39
<specialValue value="13"> <specialValue value="13">
<name>IPv6NextHeaderHBH</name> <name>IPv6NextHeaderHBH</name>
<synopsis>Packet with next header set to Hop-by-Hop <synopsis>Packet with next header set to Hop-by-Hop
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>ValidateErrorID</name> <name>ValidateErrorID</name>
<synopsis>Validate Error Types</synopsis> <synopsis>Indicating error type of the packet failed some
validation process.</synopsis>
<metadataID>12</metadataID> <metadataID>12</metadataID>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>Other</name> <name> AnyUnrecognizedValidateErrorCase</name>
<synopsis>Any other validation error.</synopsis> <synopsis> Any unrecognized validate error case.
</synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name>InvalidIPv4PacketSize</name> <name>InvalidIPv4PacketSize</name>
<synopsis>Packet size reported is less than 20 <synopsis>Packet size reported is less than 20
bytes.</synopsis> bytes.</synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>NotIPv4Packet</name> <name>NotIPv4Packet</name>
<synopsis>Packet is not IP version 4.</synopsis> <synopsis>Packet is not IP version 4.</synopsis>
</specialValue> </specialValue>
<specialValue value="3"> <specialValue value="3">
<name>InvalidIPv4HeaderLengthSize</name> <name>InvalidIPv4HeaderLengthSize</name>
<synopsis>Packet's header length is less than 5. <synopsis>Packet's header length is less than 5.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="4"> <specialValue value="4">
<name>InvalidIPv4Checksum</name> <name>InvalidIPv4Checksum</name>
<synopsis>Packet with invalid checksum.</synopsis> <synopsis>Packet with invalid checksum.</synopsis>
</specialValue> </specialValue>
<specialValue value="5"> <specialValue value="5">
<name>InvalidIPv4SrcAddr1</name> <name>InvalidIPv4SrcAddrCase1</name>
<synopsis>Packet with source address equal to <synopsis>Packet with source address equal to
255.255.255.255.</synopsis> 255.255.255.255.</synopsis>
</specialValue> </specialValue>
<specialValue value="6"> <specialValue value="6">
<name>InvalidIPv4SrcAddr2</name> <name>InvalidIPv4SrcAddrCase2</name>
<synopsis>Packet with source address 0.</synopsis> <synopsis>Packet with source address 0.</synopsis>
</specialValue> </specialValue>
<specialValue value="7"> <specialValue value="7">
<name>InvalidIPv4SrcAddr3</name> <name>InvalidIPv4SrcAddrCase3</name>
<synopsis>Packet with source address of form <synopsis>Packet with source address of form
127.any.</synopsis> 127.any.</synopsis>
</specialValue> </specialValue>
<specialValue value="8"> <specialValue value="8">
<name>InvalidIPv4SrcAddr4</name> <name>InvalidIPv4SrcAddrCase4</name>
<synopsis>Packet with source address in Class E <synopsis>Packet with source address in Class E
domain.</synopsis> domain.</synopsis>
</specialValue> </specialValue>
<specialValue value="9"> <specialValue value="9">
<name>InvalidIPv6PakcetSize</name> <name>InvalidIPv6PakcetSize</name>
<synopsis>Packet size reported is less than 40 <synopsis>Packet size reported is less than 40
bytes.</synopsis> bytes.</synopsis>
</specialValue> </specialValue>
<specialValue value="10"> <specialValue value="10">
<name>NotIPv6Packet</name> <name>NotIPv6Packet</name>
<synopsis>Packet is not IP version 6.</synopsis> <synopsis>Packet is not IP version 6.</synopsis>
</specialValue> </specialValue>
<specialValue value="11"> <specialValue value="11">
<name>InvalidIPv6SrcAddr1</name> <name>InvalidIPv6SrcAddrCase1</name>
<synopsis>Packet with multicast source address (the <synopsis>Packet with multicast source address (the
MSB of the source address is 0xFF).</synopsis> MSB of the source address is 0xFF).</synopsis>
</specialValue> </specialValue>
<specialValue value="12"> <specialValue value="12">
<name>InvalidIPv6SrcAddr2</name> <name>InvalidIPv6SrcAddrCase2</name>
<synopsis>Packet with source address set to <synopsis>Packet with source address set to
loopback(::1).</synopsis> loopback(::1).</synopsis>
</specialValue> </specialValue>
<specialValue value="13"> <specialValue value="13">
<name>InvalidIPv6DstAddr1</name> <name>InvalidIPv6DstAddrCase1</name>
<synopsis>Packet with destination set to 0 or ::1. <synopsis>Packet with destination set to 0 or ::1.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>L3PortID</name> <name>L3PortID</name>
<synopsis>ID of L3 port.</synopsis> <synopsis>ID of L3 port.</synopsis>
<metadataID>13</metadataID> <metadataID>13</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>RedirectIndex</name> <name>RedirectIndex</name>
<synopsis>Redirect Output port index.</synopsis> <synopsis>metadata CE sends to RedirectIn LFB for the
associated packet to select output port in the LFB group
output "PktsOut".</synopsis>
<metadataID>14</metadataID> <metadataID>14</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>MediaEncapInfoIndex</name> <name>MediaEncapInfoIndex</name>
<synopsis>The index for media encap table in Media encap LFB. <synopsis>An index the packet uses to look up a media
</synopsis> encapsulation table to select its encapsulation media as
well as followed encapsulation LFB.</synopsis>
<metadataID>15</metadataID> <metadataID>15</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
</metadataDefs> </metadataDefs>
</LFBLibrary> </LFBLibrary>
5. LFB Class Description 5. LFB Class Description
According to ForCES specifications, LFB (Logical Function Block) is a According to ForCES specifications, LFB (Logical Function Block) is a
well defined, logically separable functional block that resides in an well defined, logically separable functional block that resides in an
skipping to change at page 40, line 24 skipping to change at page 42, line 24
This LFB does not have a list of capabilities. This LFB does not have a list of capabilities.
5.1.2.4. Events 5.1.2.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.1.3. EtherClassifier 5.1.3. EtherClassifier
EtherClassifier LFB abstracts the process to decapsulate Ethernet EtherClassifier LFB abstracts the process to decapsulate Ethernet
packets and classify the data packets into various network layer data packets and classify them.
packets according to information included in the Ethernet packets
headers.
Input of the LFB expects all types of Ethernet packets, including 5.1.3.1. Data Handling
VLAN Ethernet types. The input is a singleton input which may
connect to an upstream LFB like EtherMACIn LFB. The input is also
capable of multiplexing to allow for multiple upstream LFBs being
connected. For instance, when L2 bridging function is enabled in
EtherMACIn LFB, some L2 bridging LFBs may be applied. In this case,
some Ethernet packets after L2 processing may have to be input to
EtherClassifier LFB for classification, while simultaneously packets
directly output from EtherMACIn may also need to input to this LFB.
Input of this LFB is capable of handling this case. Usually, every
input Ethernet packet is expected to be associated with a PHYPortID
metadatum, indicating the physical port the packet comes from. In
some cases, for instance, like in an MACinMAC case, a LogicalPortID
metadatum may be expected to associate with the Ethernet packet to
further indicate which logical port the Ethernet packet belongs to.
Note that PHYPortID metadata is always expected while LogicalPortID
metadata is optionally expected.
A VLANInputTable component is defined in the LFB to classify VLAN This LFB describes the process of decapsulating Ethernet packets and
Ethernet packets. According to IEEE VLAN specifications, all classify them into various network layer data packets according to
Ethernet packets can be recognized as VLAN types by defining that if information included in the Ethernet packets headers.
there is no VLAN encapsulation in a packet, a case with VLAN tag 0 is
considered. Therefore the table actually applies to every input
packet of the LFB. The table assigns every input packet with a new
LogicalPortID according to the packet incoming port ID and the VLAN
ID. A packet incoming port ID is defined as a physical port ID if
there is no logical port ID associated with the packet, or a logical
port ID if there is a logical port ID associated with the packet.
The VLAN ID is exactly the Vlan ID in the packet if it is a VLAN
packet, or 0 if it is not a VLAN packet. Note that a logical port ID
of a packet may be rewritten with a new one by the VLANInputTable
processing.
An EtherDispatchTable component is defined to dispatch every Ethernet TThe LFB is expected to receive all types of Ethernet packets,
packet to a group of outputs according to the logical port ID including VLAN Ethernet types, via a singleton input known as
assigned by VLANInputTable to the packet and the Ethernet type in the "EtherPktsIn", which are usually output from an upstream LFB like
Ethernet packet header. By CE configuring the dispatch table, the EtherMACIn LFB. This input is also capable of multiplexing to allow
LFB can be expected to classify various network layer protocol type for multiple upstream LFBs being connected. For instance, when L2
packets and make them output at different output port. It is then bridging function is enabled in EtherMACIn LFB, some L2 bridging LFBs
easily expected that the LFB classify packets according to protocols may be applied. In this case, some Ethernet packets after L2
like IPv4, IPv6, MPLS, ARP, ND, etc. processing may have to be input to EtherClassifier LFB for
classification, while simultaneously packets directly output from
EtherMACIn may also need to input to this LFB. This input is capable
of handling this case. Usually, all expected Ethernet Packets will
be associated with a PHYPortID metadatum, indicating the physical
port the packet comes from. In some cases, for instance, like in a
MACinMAC case, a LogicalPortID metadatum may be expected to associate
with the Ethernet packet to further indicate which logical port the
Ethernet packet belongs to. Note that PHYPortID metadata is always
expected while LogicalPortID metadata is optionally expected.
Output of the LFB is hence defined as a group output. Because there The LFB is defined with a group output known as "ClassifyOut".
may be various types of protocol packets at the output ports, the Because there may be various types of protocol packets at the output
frameproduced is defined as arbitrary for the purpose of wide ports, the produced output frame is defined as arbitrary for the
extensibility in the future. In order for downstream LFBs to use, a purpose of wide extensibility in the future. In order for downstream
bunch of metadata is produced to associate with every output packet. LFBs to use, a bunch of metadata is produced to associate with every
The medatdata contain normal information like PHYPortID. It also output packet. The medatdata, which may be used by downstream LFBs
contains information on Ethernet type, source MAC address, and for packet processing, contains the PHYPortID and it also contains
destination MAC address of its original Ethernet packet. Moreover, information on Ethernet type, source MAC address, and destination MAC
it contains information of logical port ID assigned by this LFB. address of its original Ethernet packet. Moreover, it contains
This metadata may be used by downstream LFBs for packet processing. information of logical port ID assigned by this LFB. Lastly, it may
Lastly, it may conditionally contain information like VlanID and conditionally contain information like VlanID and VlanPriority with
VlanPriority with the condition that the packet is a VLAN packet. the condition that the packet is a VLAN packet.
A MaxOutPutPorts is defined as the capability of the LFB to indicate 5.1.3.2. Components
how many classification output ports the LFB is capable.
/*discussion*/
Note that logical port ID and physical port ID mentioned above are An EtherDispatchTable array component is defined in the LFB to
all originally configured by CE, and are globally effective within an dispatch every Ethernet packet to the output group according to the
ForCES NE (Network Element). To distinguish a physical port ID from logical port ID assigned by the VLANInputTable to the packet and the
a logical port ID in the incoming port ID field of the Ethernet type in the Ethernet packet header. Each row of the array
is a struct containing a Logical Port ID, an EtherType and an Output
Index. With the CE configuring the dispatch table, the LFB can be
expected to classify various network layer protocol type packets and
output them at different output ports. It is expected that the LFB
classify packets according to protocols like IPv4, IPv6, MPLS, ARP,
ND, etc.
A VLANInputTable array component is defined in the LFB to classify
VLAN Ethernet packets. Each row of the array is a strcut containing
an Incoming Port ID, a VLAN ID and a Logical Port ID. According to
IEEE VLAN specifications, all Ethernet packets can be recognized as
VLAN types by defining that if there is no VLAN encapsulation in a
packet, a case with VLAN tag 0 is considered. Therefore the table
actually applies to every input packet of the LFB. Every input
packet is assigned with a new LogicalPortID according to the packet
incoming port ID and the VLAN ID. A packet incoming port ID is
defined as a physical port ID if there is no logical port ID
associated with the packet, or a logical port ID if there is a
logical port ID associated with the packet. The VLAN ID is exactly
the Vlan ID in the packet if it is a VLAN packet, or 0 if it is not a
VLAN packet. Note that a logical port ID of a packet may be
rewritten with a new one by the VLANInputTable processing.
Note that the logical port ID and physical port ID mentioned above
are all originally configured by CE, and are globally effective
within an ForCES NE (Network Element). To distinguish a physical
port ID from a logical port ID in the incoming port ID field of the
VLANInputTable, physical port ID and logical port ID must be assigned VLANInputTable, physical port ID and logical port ID must be assigned
with separate number spaces. /*discussion */ with separate number spaces.
There are also some other components, capabilities, events defined in An array component, EtherClassifyStats, defines a set of statistics
the LFB for various purposes. See section 6 for detailed XML for this LFB, measuring the number of packets per EtherType. Each
definitions of the LFB. row of the array is a struct containing an EtherType and a Packet
number.
5.1.4. EtherEncapsulator 5.1.3.3. Capabilities
EtherEncapsulator LFB abstracts the process to encapsulate IP packets This LFB does not have a list of capabilities.
to Ethernet packets.
Input of the LFB expects types of IP packets, including IPv4 and IPv6 5.1.3.4. Events
types. The input is a singleton one which may connect to an upstream
LFB like an IPv4NextHop, an IPv6NextHop, or any LFB which requires to
output packets for Ethernet encapsulation. The input is capable of
multiplexing to allow for multiple upstream LFBs being connected.
For instance, an IPv4NextHop or an IPv6NextHop may concurrently
exist, and some L2 bridging LFBs may also output packets to this LFB
simultaneously. Input of this LFB is capable of handling this case.
Usually, every input Ethernet packet is expected to be associated
with an output logical port ID and a next hop IP address as its
metadata. In the case when L2 bridging function is implemented, an
input packet may also optionally receive a VLAN priority as its
metadata. In this case, default value for this metadata is set to 0.
There are several outputs for this LFB. One singleton output is for This LFB has no events specified.
normal success packet output. Packets which have found Ethernet L2
information and have been successfully encapsulated to an Ethernet
packet will output from this port to downstream LFB. Note that this
LFB specifies to use Ethernet II as its Ethernet encapsulation type.
Success output also produces an output logical port ID as metadatum
of every output packet for a downstream LFB to decide which logical
port the packet should go out. The downstream LFB usually dispatches
the packets based on its associated output logical port ID. Hence, a
generic dispatch LFB as defined in Section 5.6.1 may be adopted for
dispatching packets based on output logical port ID.
Note that in some implementations of LFBs topology, the processing to 5.1.4. EtherEncap
dispatch packets based on an output logical port ID may also take
place before an Ethernet encapsulation,i.e., packets coming into the
encapsulator LFB have already been switched to individual logical
output port paths. In this case, the EtherEncap LFB success output
may be directly connected to a downstream LFB like an EtherMACOut
LFB.
Another singleton output is for IPv4 packets that are unfortunately The EtherEncap LFB abstracts the process to replace or attach
unable to find Ethernet L2 encapsulation information by ARP table in appropriate Ethernet headers to the packet.
the LFB. In this case, a copy of the packets may need to be
redirected to an ARP LFB in the FE, or to CE if ARP function is
implemented by CE. More importantly, a next hop IP address metadata
should be associated with every packet output here. When an ARP LFB
or CE receives these packets and associated next hop IP address
metadata, it may be expected to generate ARP protocol messages based
on these packets next hop IP addresses to try to get L2 information
for these packets. Refreshed L2 information is then able to be added
in ARP table in this encapsulator LFB by ARP LFB or by CE. As a
result, these packets are then able to successfully find L2
information and be encapsulated to Ethernet packets, and output via
the normal success output to downstream LFB. (Editorial note1: may
need discussion on what more metadata this output packets need? Note
that the packets may be redirected to CE and CE should know what the
purpose of the packets for. A metadata may need to indicate this.
Editorial note2: we may adopt another way to address the case of
packets unable to do ARP. The packets may be redirected to ARP LFB
or CE without keeping a copy of them in this encapsulator LFB. We
expect that after ARP LFB or CE have processed ARP requests based on
the packets, the packets will be redirected back from ARP LFB or CE
to this encapsulator LFB for Ethernet encapsulation. At this time,
it is hoped the ARP table has been refreshed with new L2 information
that will make these packets able to find)
A more singleton output is for IPv6 packets that are unfortunately 5.1.4.1. Data Handling
unable to find Ethernet L2 encapsulation information by Neighbor
table in the LFB. In this case, a copy of the packets may need to be
redirected to an ND LFB in the FE, or to CE if IPv6 Neighbor
discovery function is implemented by CE. More importantly, a next
hop IP address metadata should be associated with every packet output
here. When the ND LFB or CE receives these packets and associated
next hop IP address metadata, it may be expected to generate neighbor
discovery protocol messages based on these packets next hop IP
addresses to try to get L2 information for these packets. Refreshed
L2 information is then able to be added in neighbor table in this LFB
by ND LFB or by CE. As a result, these packets are then able to
successfully find L2 information and be encapsulated to Ethernet
packets, and output via the normal success output to downstream
LFB.(Editorial note: may need discussion on what more metadata this
output packets need? Note that the packets may be redirected to CE
and CE should know what the purpose of the packets for. A metadata
may need to indicate this)
A singleton output is specifically defined for exception packets This LFB abstracts the process to encapsulate IP packets to Ethernet
output. All packets that are abnormal during the operations in this packets according to the L2 information.
LFB are output via this port. Currently, only one abnormal case is
defined, that is, packets can not find proper information in a VLAN
output table.
The VLAN output table is defined as the component of the LFB. The The LFB is expected to receive types of IP packets, including IPv4
table uses a logical port ID as an index to find a VLAN ID and a new and IPv6 types, via a singleton one known as "EncapIn" which may be
output logical port ID. In reality, the logical port ID applied here connected to an upstream LFB like an IPv4NextHop, an IPv6NextHop,
is the output logical port ID received from every input packet in its BasicMetadataDispatch, or any LFB which requires to output packets
associated metadata. According to IEEE VLAN specifications, all for Ethernet encapsulation. The LFB always expects from upstream
Ethernet packets can be recognized as VLAN types by defining that if LFBs the MediaEncapInfoIndex metadata which is used as an index to
there is no VLAN encapsulation in a packet, a case with VLAN tag 0 is lookup the Encapsulation Table. Optinally an input packet may be
considered. Therefore, every input IP packet actually has to look up accompanied by a Vlan priority metadata. In this case, default value
the VLAN output table to find out a VLAN ID and a new output logical for the metadata is 0.
port ID according to its original logical port ID..
The ARP table in the LFB is defined as a component of the LFB. The Two singleton output ports are defined to output results.
table is for IPv4 packet to find its next hop Ethernet layer MAC
addresses. Input IPv4 packet will use an output logical port ID
which is got by looking up the VLAN output table, and a next hop IPv4
address which is got by upstream next hop applicator LFB, to look up
the ARP table to find the Ethernet L2 information, i.e., the source
MAC address and destination MAC address.
The neighbor table is defined as another component of the LFB. The The first singleton output known as "SuccessOut". Upon a successful
table is for IPv6 packet to find its next hop Ethernet layer MAC table lookup, the destination and source MAC addresses, and the
addresses. Like the ARP table, input IPv6 packet will use its output logical media port (L2PortID) are found in the matching table entry.
logical port ID got from looking up the VLAN output table, and the The CE may set the VlanId in case VLANs are used. By default the
packet next hop IPv4 address got by upstream next hop applicator LFB, table entry for VlanId of 0 is used as per IEEE rules. Whatever the
to look up the neighbor table to find the Ethernet source MAC address value of VlanID is, if the Input metadata VlanPriority is non-zero,
and destination MAC address. the packet will have a VLAN tag. If the VlanPriority and the VlanID
are all zero, there is no VLAN tag to this packet. After replacing
or attaching the appropriate Ethernet headers to the packet is
complete, the packet is passed out on the "SuccessOut" LFB port to a
downstream LFB instance alongside with the L2PortID.
As will be described in the address resolution LFBs section (section The second singleton output known as "ExceptionOut", which will
5.4), Layer 2 address resolution protocols may be implemented with output packets for which the table lookup fails, along with an
two choices. One is by FE with specific address resolution LFB, like additional ExceptionID metadata. Currently defined exception types
an ARP LFB or an ND LFB. The other is to redirect address resolution only include the following case:
protocol messages to CE for CE to implement the function.
As described in section 5.4, the ARP LFB defines the ARP table in o MediaEncapInfoIndex value is not allocated in the EncapTable.
this encapsulator LFB as its alias, and the ND LFB defines the
neighbor table as its alias. This means that the ARP table or the
neighbor table will be maintained or refreshed by the ARP LFB or the
ND LFB when the LFBs are used.
Note that the ARP table and the neighbor table defined in this LFB The upstream LFB may be programmed by the CE to pass along a
are all with property of read-write. CE can also configure the MediaEncapInfoIndex that does not exist in the EncapTable. That is
tables by ForCES protocol [RFC5810]. This makes possible that IPv4 to allow for resolution of the L2 headers, if needed, to be made at
ARP protocol or IPv6 Neighbor Discovery protocol may be implemented the L2 encapsulation level in this case(ethernet) via ARP, or ND (or
at CE side,i.e., after CE manages an ARP or Neighbor discovery other methods depending on the link layer technology) when a table
protocol and gets address resolution results, CE can configure them miss occurs.
to an ARP or neighbor table in FE.
With all the information got from VLAN table and ARP or Neighbor For neighbor L2 header resolution(table miss exception), the
table, input IPv4 or IPv6 packets are then able to be encapsulated to processing LFB may pass this packet to the CE via the redirect LFB or
Ethernet layer packets. Note that according to IEEE 802.1Q, if input FE software or another LFB instance for further resolution. In such
packets are with non-zero VLAN priority metadata, the packets will a case the metadata NexthopIPv4Addr or NexthopIPv6Addr generated by
always be encapsulated with a VLAN tag, no matter the value of VLAN Nexthop LFB is also passed to the exception handling. Such an IP
ID is zero or not. If the VLAN priority and the VLAN ID are all address could be used to do activities such as ARP or ND by the
zero, the packets will be encapsulated without a VLAN tag. handler it is passed to.
Successfully encapsulated packets are then output via success output The result of the L2 resolution is to update the EncapTable as well
port. as the Nexthop LFB so subsequent packets do not fail EncapTable
lookup. The EtherEncap LFB does not make any assumptions of how the
EncapTable is updated by the CE (or whether ARP/ND is used
dynamically or static maps exist).
There are also some other components, capabilities, events defined in Downstream neighboring LFB instances could be either an EtherMACOut
the LFB for various purposes. See section 6 for detailed XML type or a BasicMetadataDispatch type. If the final packet L2
definitions of the LFB. processing is possible to be on per-media-port basis or resides on a
different FE or in cases where L2 header resolution is needed, then
the model makes sense to use a BasicMetadataDispatch LFB to fanout to
different LFB instances. If there is a direct egress port point,
then the model makes sense to have a downstream LFB instance be an
EtherMACOut.
5.1.4.2. Components
This LFB has only one component named EncapTable which is defined as
an array. Each row of the array is a struct containing the
destination MAC address, the source MAC address, the VLAN ID with a
default value of zero and the output logical L2 port ID.
5.1.4.3. Capabilities
This LFB does not have a list of capabilities.
5.1.4.4. Events
This LFB does not have any events specified.
5.1.5. EtherMACOut 5.1.5. EtherMACOut
EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. EtherMACOut LFB abstracts an Ethernet port at MAC data link layer.
This LFB describes Ethernet packet output process. Ethernet output This LFB describes Ethernet packet output process. Ethernet output
functions are closely related to Ethernet input functions, therefore functions are closely related to Ethernet input functions, therefore
many components defined in this LFB are as aliases of EtherMACIn LFB many components defined in this LFB are as aliases of EtherMACIn LFB
components. components.
5.1.5.1. Data Handling 5.1.5.1. Data Handling
skipping to change at page 51, line 7 skipping to change at page 51, line 47
done in FE to translate attributes defined by this document into real done in FE to translate attributes defined by this document into real
attributes the implementation has actually applied. attributes the implementation has actually applied.
Based on the IP forwarding abstraction, two kind of typical IP Based on the IP forwarding abstraction, two kind of typical IP
unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next
hop application LFB. They are further distinguished by IPv4 and IPv6 hop application LFB. They are further distinguished by IPv4 and IPv6
protocols. protocols.
5.3.1. IPv4UcastLPM 5.3.1. IPv4UcastLPM
The LFB abstracts the process for IPv4 unicast LPM table looking up. The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match
(LPM) process..
Input of the LFB always expects to receive IPv4 unicast packets. An This LFB also provides facilities to support users to implement
IPv4 prefix table is defined as a component for the LFB to provide equal-cost multi-path routing (ECMP) or reverse path forwarding
forwarding information for every input packet. The destination IPv4 (RPF). However, this LFB itself does not provide ECMP or RPF. To
address of every packet is as the index to look up the table with the fully implement ECMP or RPF, additional specific LFBs, like a
rule of longest prefix matching(LPM). A hop selector is the matching specific ECMP LFB or an RPF LFB, will have to be defined. This work
result, which will be output to downstream LFBs as an index for next may be done in the future version of the document.
hop information.
Normal output of the LFB is a singleton output, which will output 5.3.1.1. Data Handling
IPv4 unicast packet that has passed the LPM lookup and got a hop
This LFB performs the IPv4 unicast LPM table looking up. It always
expects as input IPv4 unicast packets from one singleton input known
as "PktsIn". Then the LFB uses the destination IPv4 address of every
packet as index to look up the IPv4 prefix table and generate a hop
selector as the matching result. This result will associate to the
packet as a metadatum to output to downstream LFBs, and will usually
be used there as an index to find more next hop information.
Three singleton output ports are defined to output LPM results.
The first singleton output known as "NormalOut", which will output
IPv4 unicast packets that has passed the LPM lookup and got a hop
selector as the lookup result. The hop selector is associated with selector as the lookup result. The hop selector is associated with
the packet as a metadatum. Followed the normal output of the LPM LFB the packet as a metadatum. Followed the normal output of the LPM LFB
is usually a next hop applicator LFB. The LFB receives packets with is usually a next hop application LFB, like an IPv4NextHop LFB.
their next hop IDs and based on the next hop IDs to forward the
packets. A hop selector associated with every packet from the normal
output will directly act as a next hop ID for a next hop applicator
LFB..
The LFB is defined to provide some facilities to support users to The second singleton output known as "ECMPOut" is defined to provide
implement equal-cost multi-path routing (ECMP) or reverse path support for users wishing to implement ECMP.
forwarding (RPF). However, this LFB itself does not provide ECMP or
RPF. To implement ECMP or RPF, additional specific LFBs, like a
specific ECMP LFB, will have to be defined. This work may be done in
the future version of the document.
For the LFB to support ECMP, an ECMP flag is defined in the prefix An ECMP flag is defined in the LPM table to enable the LFB to support
table entries. When the flag is set to true, it indicates this table ECMP. When a table entry is created with the flag set true, it
entry is for ECMP only. In this case, the hop selector in this table indicates this table entry is for ECMP only. A packet, which has
entry will be used as an index for a downstream specific ECMP LFB to passed through this prefix lookup, will always output from "ECMPOut"
find its correspondent next hop IDs. When ECMP is applied, it will output port, with the hop selector being its lookup result. The
usually get multiple next hops information. output will usually directly go to a downstream ECMP processing LFB,
where the hop selector can usually further generate optimized one or
multiple next hop routes by use of ECMP algorithms.
To distinguish normal output from ECMP case output, a specific ECMP A default route flag is defined in the LPM table to enable the LFB to
output is defined. A packet, which has passed through prefix table support a default route, and loose RPF also. When set true, the
entry lookup with true ECMP flag, will always output from this port, table entry is identified a default route and as a forbidden route
with the hop selector being its lookup result. The output will for RPF also. If a user wants to implement RPF on FE, a specific RPF
usually directly go to a downstream ECMP processing LFB. In the ECMP LFB will have to be defined. In such RPF LFB, a component can be
LFB, based on the hop selector, multiple next hop IDs may be found, defined as an alias of the prefix table component of this LFB as
and more ECMP algorithms may be applied to optimize the route. As described below.
the result of the ECMP LFB, it will output optimized one or multiple
next hop IDs to its downstream LFB that is usually a next hop
applicator LFB.
For the LFB to support RPF, a default route flag is defined in the The final singleton output is known as "ExceptionOut" and is defined
prefix table entry. When set true, the prefix entry is identified as to allow exception packets to output here. Exceptions include cases
a default route, and also as a forbidden route for RPF. To implement like:
various RPF, one or more specific LFBs have to be defined. This job
may be done for the future version of the library.
An exception output is defined to allow some exceptional packets to o Packets can not find any routes in the prefix table.
output here. Exceptions include cases like packets can not find any
routes by the prefix table.
There are also some other components defined in the LFB for various The upstream neighboring LFB of this LFB is usually IPv4Validator
purposes. See section 6 for detailed XML definitions of the LFB. LFB. If RPF is to be adopted, the upstream can be an RPF LFB, when
defined.
The downstream neighboring LFB is usually IPv4NextHop LFB. If ECMP
is adopted, the downstream can be an ECMP LFB, when defined.
5.3.1.2. Components
This LFB has two components.
The IPv4PrefixTable component is defined as an array component of the
LFB. Each row of the array contains an IPv4 adrress, a Prefix
length, a Hop Selector, an ECMP flag and a Default Route flag. The
LFB uses the destination IPv4 address of every input packet as index
to look up this table to get a hop selector as the result. The ECMP
flag is for the LFB to support ECMP.The default route flag is for the
LFB to support a default route and for loose RPF.
The IPv4UcastLPMStats component is a struct component which collects
statistics information, including the total number of input packets
received, the IPv4 packets forwarded by this LFB and the number of IP
datagrams discarded due to no route found.
5.3.1.3. Capabilities
This LFB does not have a list of capabilities
5.3.1.4. Events
This LFB does not have any events specified.
5.3.2. IPv4NextHop 5.3.2. IPv4NextHop
This LFB abstracts the process of next hop information application to This LFB abstracts the process of selecting ipv4 next hop action.
IPv4 packets.
The LFB receives an IPv4 packet with an associated next hop ID, and 5.3.2.1. Data Handling
uses the ID to look up a next hop table to find an appropriate output
port from the LFB. Simultaneously, the LFB also implements TTL
operation and checksum recalculation of every IPv4 packet received.
Input of the LFB is a singleton one which expects to receive IPv4 The LFB abstracts the process of next hop information application to
unicast packets and hop selector metadata from an upstream LFB. IPv4 packets. It receives an IPv4 packet with an associated next hop
Usually, the upstream LFB is directly an IPv4UnicastLPM LFB_while it ID, and uses the ID to look up a next hop table to find an
is possible some other upstream LFB may be applied. For instance, appropriate output port from the LFB.
when ECMP is supported, the upstream LFB may be some specific ECMP
LFB.
The next hop ID in hop selector metadata of a packet is then used as The LFB is expected to receive unicast IPv4 packets, via a singleton
an index to look up a next hop table defined in the LFB. Via this input known as "PcktsIn" along with a HopSelector metadata which is
table and the next hop index, important information for forwarding used as an index to lookup the NextHop table. Data processing
the packet is found. Every next hop table entry includes the involves the forwarding TTL decrement and checksum recalculation.
following information:
output logical port ID, which will be used by downstream LFBs to Two output ports are defined to output results.
find proper output port.
next hop option, which decides if packets with next hop of this The first output is a group output port known as "SuccessOut". On
table entry are destinated to locally attached hosts or not. successful data processing the packet is sent out an LFB-port from
Locally attached hosts are hosts in the same subnet with this within the LFB port group as selected by the LFBOutputSelectIndex
router. Next hop option is marked as 'forwarded to locally value of the matched table entry. The packet is sent to a downstream
attached host' if the next hop entry is for locally attached hosts LFB alongside with the L3PortID and MediaEncapInfoIndex metadata.
delivery. All other next hop entry will be marked with 'normal
forwarding'. If a data packet passes through next hop entries
with its next hop option marked with forwarded to locally attached
host, the next hop IP address metadata associated with the data
packet when output from the LFB will be forced to set to the
destination IP address of the data packet. If a data packet
passes through a next hop entry with its option being normal
forwarding, the next hop IP address metadata at output will be set
to the next hop IP address as indicated by this next hop entry.
Advantage to define this next hop option for locally attached
hosts is, in this way, the next hop entry number may be greatly
reduced in the case there are a vast number of locally attached
hosts.
next hop IP address, which will be used by downstream LFB to find The second output is a singleton output port known as "ExceptionOut",
proper output port IP address for this packet. Note that when which will output packets for which the data processing failed, along
next hop option is set to 'forwarded to locally attached host', with an additional ExceptionID metadata to indicate what caused the
this entry field becomes invalid. In this case the next hop IP exception. Currently defined exception types include:
address is assigned directly by destination IP address of the data
packet pass through this entry check.
encapsulation output index, which is used by data packet to find o The HopSelector is invalid
proper output of this LFB. Usually, this index can be used to
indicate which encapsulation followed the LFB may be applied to
data packets pass through this next hop entry check and to
classify the packets to different instance of a group output port.
Moreover, this index can also be used to purely indicate output
port instance to act as a classifier based on next hop IDs. For
instance, a next hop table entry can be defined with its
encapsulation output index being directed to an output port which
is followed with LFBs that will redirect data packets to Control
Element(CE). A next hop entry can also be defined for some data
packets that need special local processing of the Forwarding
Element(FE). In this case it is not really acting as an
encapsulation index, rather a pure output index.
As a result, the LFB is defined with two output ports. One is for o The MTU for outgoing interface is less than the packet size
success output and another is for exception output. Success output
is a group output, with an index to indicate which output instance in
the group is adopted. The index is exactly the encapsulation output
index described above. Downstream LFBs connected to the success
output group may be various LFBs for encapsulation like LFBs for
Ethernet encapsulation and for PPP encapsulation, various LFBs for
local processing, and LFBs for redirecting packets to CE for
processing. Next hop table uses the encapsulation output index to
indicate which port instance in the output group a packet should go.
Every port instance of the success output group will produce metadata o ICMP packet needs to be generated
of output logical port ID and next hop IP address for every output
packet. These metadata will be used by downstream LFBs to further
implementing forwarding or local processing. Note that for next hop
option marked as local host processing, the next hop IP address
metadata for the packet is exactly substituted with the destination
IP address of the packet.
The exception output of the LFB is a singleton output. It outputs Downstream neighboring LFB instances could be either a
packets with exceptional cases. An exception ID further indicates BasicMetadataDispatch type, used to fanout to different LFB instances
the exception reasons. Exception may happen when a hop selector is or a media encapsulation related type, such as an EtherEncap type or
found invalid, or ICMP packets need to be generated (Editorial note: a RedirectOut type. For example, there are Ethernet and other tunnel
more discussions here), etc. The exception ID is also produced as a Encapsulation, then BasicMetadataDispatch can use the L3PortID
metadata by the output to be transmitted to a downstream LFB. metadata to dispatch packets to different Encapsulator.
There are also some other components defined in the LFB for various 5.3.2.2. Components
purposes. See section 6 for detailed XML definitions of the LFB.
This LFB has only one component named IPv4NextHopTable which is
defined as an array. Each row of the array is a struct containing:
o The L3PortID, which is the ID of the Logical Output Port that is
passed onto the neighboring LFB instance. This ID indicates what
port to the neighbor is as defined by L3.
o MTU, the Maximum Transmission Unit for the outgoing port.
o NextHopIPAddr, the IPv4 next hop Address.
o MediaEncapInfoIndex, the index we pass onto the neighboring LFB
instance. This index is used to lookup a table (typically media
encapsulatation related) further downstream. The CE sets it to a
value that is not allocated in downstream LFB tables. (If a
downstream LFB lookup fails to find it, it indicates some other
way to resolve it may be needed.)
o LFBOutputSelectIndex, the LFB Group output port index to select
downstream LFB port. This index exactly is the FromPortIndex for
the port group "SuccessOut" in the table LFBTopology of FEObject
LFB as defined for the Nexthop LFB.
5.3.2.3. Capabilities
This LFB does not have a list of capabilities
5.3.2.4. Events
This LFB does not have any events specified.
5.3.3. IPv6UcastLPM 5.3.3. IPv6UcastLPM
The LFB abstracts the process for IPv6 unicast LPM table looking up. The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match
(LPM) process. The definition of this LFB is similar to the
IPv4UcastLPM LFB except that all IP addresses refer to IPv6
addresses.
Definitions of this IPv6UcastLPM LFB is very identical to This LFB also provides facilities to support users to implement
IPv4UcastLPM LFB except that all IP addresses related are changed equal-cost multi-path routing (ECMP) or reverse path forwarding
from IPv4 addresses to IPv6 addresses. See section 6 for detailed (RPF). However, this LFB itself does not provide ECMP or RPF. To
XML definitions of this LFB. fully implement ECMP or RPF, additional specific LFBs, like a
specific ECMP LFB or an RPF LFB, will have to be defined. This work
may be done in the future version of the document.
5.3.3.1. Data Handling
This LFB performs the IPv6 unicast LPM table looking up. It always
expects as input IPv6 unicast packets from one singleton input known
as "PktsIn". Then the LFB uses the destination IPv6 address of every
packet as index to look up the IPv6 prefix table and generate a hop
selector as the matching result. This result will associate to the
packet as a metadatum to output to downstream LFBs, and will usually
be used there as an index to find more next hop information.
Three singleton output ports are defined to output LPM results.
The first singleton output known as "NormalOut", which will output
IPv6 unicast packets that has passed the LPM lookup and got a hop
selector as the lookup result. The hop selector is associated with
the packet as a metadatum. Followed the normal output of the LPM LFB
is usually a next hop application LFB, like an IPv6NextHop LFB.
The second singleton output known as "ECMPOut" is defined to provide
support for users wishing to implement ECMP.
An ECMP flag is defined in the LPM table to enable the LFB to support
ECMP. When a table entry is created with the flag set true, it
indicates this table entry is for ECMP only. A packet, which has
passed through this prefix lookup, will always output from "ECMPOut"
output port, with the hop selector being its lookup result. The
output will usually directly go to a downstream ECMP processing LFB,
where the hop selector can usually further generate optimized one or
multiple next hop routes by use of ECMP algorithms.
A default route flag is defined in the LPM table to enable the LFB to
support a default route, and loose RPF also. When set true, the
table entry is identified a default route and as a forbidden route
for RPF also. If a user wants to implement RPF on FE, a specific RPF
LFB will have to be defined. In such RPF LFB, a component can be
defined as an alias of the prefix table component of this LFB as
described below.
The final singleton output is known as "ExceptionOut" and is defined
to allow exception packets to output here. Exceptions include cases
like:
o Packets can not find any routes in the prefix table.
The upstream neighboring LFB of this LFB is usually IPv6Validator
LFB. If RPF is to be adopted, the upstream can be an RPF LFB, when
defined.
The downstream neighboring LFB is usually an IPv6NextHop LFB. If
ECMP is adopted, the downstream can be an ECMP LFB, when defined.
5.3.3.2. Components
This LFB has two components.
The IPv6PrefixTable component is defined as an array component of the
LFB. Each row of the array contains an IPv6 adrress, a Prefix
length, a Hop Selector, an ECMP flag and a Default Route flag. The
LFB uses the destination IPv6 address of every input packet as index
to look up this table to get a hop selector as the result. The ECMP
flag is for the LFB to support ECMP. The default route flag is for
the LFB to support a default route and for loose RPF.
The IPv6UcastLPMStats component is a struct component which collects
statistics information, including the total number of input packets
received, the IPv6 packets forwarded by this LFB and the number of IP
datagrams discarded due to no route found.
5.3.3.3. Capabilities
This LFB does not have a list of capabilities
5.3.3.4. Events
This LFB does not have any events specified.
5.3.4. IPv6NextHop 5.3.4. IPv6NextHop
This LFB abstracts the process of next hop information application to This LFB abstracts the process of selecting IPv6 next hop action.
IPv6 packets.
Definitions of this IPv6NextHop LFB is very identical to IPv4NextHop 5.3.4.1. Data Handling
LFB except that all IP addresses related are changed from IPv4
addresses to IPv6 addresses. See section 6 for detailed XML The LFB abstracts the process of next hop information application to
definitions of this LFB. IPv6 packets. It receives an IPv6 packet with an associated next hop
ID, and uses the ID to look up a next hop table to find an
appropriate output port from the LFB.
The LFB is expected to receive unicast IPv6 packets, via a singleton
input known as "PcktsIn" along with a HopSelector metadata which is
used as an index to lookup the NextHop table.
Two output ports are defined to output results.
The first output is a group output port known as "SuccessOut". On
successful data processing the packet is sent out an LFB-port from
within the LFB port group as selected by the LFBOutputSelectIndex
value of the matched table entry. The packet is sent to a downstream
LFB alongside with the L3PortID and MediaEncapInfoIndex metadata.
The second output is a singleton output port known as "ExceptionOut",
which will output packets for which the data processing failed, along
with an additional ExceptionID metadata to indicate what caused the
exception. Currently defined exception types include:
o The HopSelector is invalid
o The MTU for outgoing interface is less than the packet size
o ICMP packet needs to be generated
Downstream neighboring LFB instances could be either a
BasicMetadataDispatch type, used to fanout to different LFB instances
or a media encapsulatation related type, such as an EtherEncap type
or a RedirectOut type. For example, there are Ethernet and other
tunnel Encapsulation, then BasicMetadataDispatch can use the L3PortID
metadata to dispatch packets to different Encapsulator.
5.3.4.2. Components
This LFB has only one component named IPv6NextHopTable which is
defined as an array. Each row of the array is a struct containing:
o The L3PortID, which is the ID of the Logical Output Port that is
passed onto the neighboring LFB instance. This ID indicates what
port to the neighbor is as defined by L3.
o MTU, the Maximum Transmission Unit for the outgoing port.
o NextHopIPAddr, the IPv6 next hop Address.
o MediaEncapInfoIndex, the index we pass onto the neighboring LFB
instance. This index is used to lookup a table (typically media
encapsulatation related) further downstream. The CE sets it to a
value that is not allocated in downstream LFB tables. (If a
downstream LFB lookup fails to find it, it indicates some other
way to resolve it may be needed.)
o LFBOutputSelectIndex, the LFB Group output port index to select
downstream LFB port. This index exactly is the FromPortIndex for
the port group "SuccessOut" in the table LFBTopology of FEObject
LFB as defined for the Nexthop LFB.
5.3.4.3. Capabilities
This LFB does not have a list of capabilities
5.3.4.4. Events
This LFB does not have any events specified.
5.4. Redirect LFBs 5.4. Redirect LFBs
Redirect LFBs abstract data packets transportation process between CE Redirect LFBs abstract data packets transportation process between CE
and FE. Some packets output from some LFBs may have to be delivered and FE. Some packets output from some LFBs may have to be delivered
to CE for further processing, and some packets generated by CE may to CE for further processing, and some packets generated by CE may
have to be delivered to FE and further to some specific LFBs for data have to be delivered to FE and further to some specific LFBs for data
path processing. According to RFC 5810 [RFC5810], data packets and path processing. According to RFC 5810 [RFC5810], data packets and
their associated metadata are encapsulated in ForCES redirect message their associated metadata are encapsulated in ForCES redirect message
for transportation between CE and FE. We define two LFBs to abstract for transportation between CE and FE. We define two LFBs to abstract
the process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an the process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an
LFB topology of an FE, only one RedirectIn LFB instance and one LFB topology of an FE, only one RedirectIn LFB instance and one
RedirectOut LFB instance exist. RedirectOut LFB instance exist.
5.4.1. RedirectIn 5.4.1. RedirectIn
A RedirectIn LFB abstracts the process for CE to inject data packets RedirectIn LFB abstracts the process for the CE to inject data
into FE LFB topology so as to input data packets into FE data paths. packets into the FE data path.
From LFB topology point of view, the RedirectIn LFB acts as a source 5.4.1.1. Data Handling
point for data packets coming from CE, therefore the RedirectIn LFB
is defined with only one output, while without any input.
Output of the RedirectIn LFB is defined as a group output. Packets A RedirectIn LFB abstracts the process for the CE to inject data
produced by the output will have arbitrary frame types decided by CE packets into the FE LFB topology so as to input data packets into FE
which generates the packets. Possible frames may include IPv4, IPv6, data paths. From LFB topology point of view, the RedirectIn LFB acts
or ARP protocol packets. CE may associate some metadata to indicate as a source point for data packets coming from CE, therefore the
the frame types. CE may also associate other metadata to data RedirectIn LFB is defined with only one output, while without any
packets to indicate various information on the packets. Among them, input.
there MUST exist a 'RedirectIndex' metadata, which is an integer
acting as an index. When CE transmits the metadata and a binging
packet to a RedirectIn LFB, the LFB will read the metadata and output
the packet to one of its group output port instance, whose port index
is just as indicated by the metadata. Detailed XML definition of the
metadata is in the XML for base type library as in Section 4.4.
All metadata from CE other than the 'RedirectIndex' metadata will The RedirectIn LFB has only one output defined as a group output
known as "PktsOut". Packets produced by this output will have
arbitrary frame types decided by the CE which generated the packets.
Possible frames may include IPv4, IPv6, or ARP protocol packets. The
CE may associate some metadata to indicate the frame types and may
also associate other metadata to indicate various information on the
packets. Among them, there MUST exist a 'RedirectIndex' metadata,
which is an integer acting as an index. When the CE transmits the
metadata along with the packet to a RedirectIn LFB, the LFB will read
the RedirectIndex metadata and output the packet to one of its group
output port instance, whose port index is indicated by the metadata.
All metadata from the CE other than the 'RedirectIndex' metadata will
output from the RedirectIn LFB along with their binding packets. output from the RedirectIn LFB along with their binding packets.
Note that, a packet without a 'RedirectIndex' metadata associated Note that, a packet without a 'RedirectIndex' metadata associated
will be dropped by the LFB. will be dropped by the LFB.
There is no component defined for current version of RedirectIn LFB. 5.4.1.2. Components
Detailed XML definitions of the LFB can be found in Section 6.
There are no components defined for the current version of RedirectIn
LFB.
5.4.1.3. Capabilities
This LFB does not have a list of capabilities
5.4.1.4. Events
This LFB does not have any events specified.
5.4.2. RedirectOut 5.4.2. RedirectOut
A RedirectOut LFB abstracts the process for LFBs in FE to deliver RedirectOut LFB abstracts the process for LFBs in the FE to deliver
data packets to CE. From LFB topology point of view, the RedirectOut data packets to the CE.
LFB acts as a sink point for data packets going to CE, therefore the
RedirectOut LFB is defined with only one input, while without any
output.
Input of the RedirectOut LFB is defined as a singleton input, but it 5.4.2.1. Data Handling
is capable of receiving packets from multiple LFBs by multiplexing
the singleton input. Packets expected by the input will have
arbitrary frame types. All metadata associated with the input
packets will be delivered to CE via a ForCES protocol redirect
message [RFC5810]. The input will expect all types of metadata.
There is no component defined for current version of RedirectOut LFB. A RedirectOut LFB abstracts the process for LFBs in the FE to deliver
Detailed XML definitions of the LFB can be found in Section 6. data packets to the CE. From the LFB's topology point of view, the
RedirectOut LFB acts as a sink point for data packets going to the
CE, therefore the RedirectOut LFB is defined with only one input,
while without any output.
The RedirectOut LFB has only one singleton input known as "PktsIn",
but is capable of receiving packets from multiple LFBs by
multiplexing this input. The input expects any kind of frame type
therefore the frame type has been specified as arbitrary and also all
types of metadata are expected. All metadata associated with the
input packets will be delivered to CE via the ForCES protocol
redirect message [RFC5810].
5.4.2.2. Components
There are no components defined for the current version of
RedirectOut LFB.
5.4.2.3. Capabilities
This LFB does not have a list of capabilities
5.4.2.4. Events
This LFB does not have any events specified.
5.5. General Purpose LFBs 5.5. General Purpose LFBs
5.5.1. BasicMetadataDispatch 5.5.1. BasicMetadataDispatch
A basic medatata dispatch LFB is defined to abstract a process in A basic medatata dispatch LFB is defined to abstract the process in
which a packet is dispatched to some path based on its associated which a packet is dispatched to some path based on its associated
metadata value. metadata value.
The LFB is with a singleton input. Packets of arbitrary frame types 5.5.1.1. Data Handling
can input into the LFB. Whereas, every input packet is required to
be associated with a metadata that will be used by the LFB to do
dispatch. If a packet is not associated with such metadata, the
packet will be dropped inside the LFB.
A group of output is defined to output packets according to a The BasicMetadataDispatch LFB provides the function to dispatch input
MetaDispatchTable as defined a component in the LFB. The table packets to a group output according to a metadata and a dispatch
contains the fields of a metadata ID, a metadata value, and an output table.
port index. A packet, if it is associated with a metadata with the
metadata ID, will be output to the group port instance with the index
corresponding to the metadata value in the table. The metadata value
ussed by the table is required with an interger data type. This
means this LFB currently only allow a metadata with an interger value
to be used for dispatch.
Moreover, the LFB is defined with only one metadata adopted for The BasicMetadataDispatch has only one singleton input known as
dispatch, i.e., the metadata ID in the dispatch table is always the "PktsIn" and expects any kind of frame type, therefore it has been
same for all table rows. specified as arbitrary, along with a metadata that will be used by
the LFB to do the dispatch. If a packet is not associated with such
a metadata, the packet will be dropped inside the LFB.
The BasicMetadataDispatch LFB has only one output defined as a group
output known as "PktsOut". A packet, if it is associated with a
metadata with the metadata ID, will be output to the group port
instance with the index corresponding to the metadata value in the
Metadata Dispatch table. Currently the BasicMetadataDispatch only
allows an interger value for the metadata to be used for dispatch.
The BasicMetadataDispatch LFB is currently defined with only one
metadata adopted for dispatch, i.e., the metadata ID in the dispatch
table is always the same for all table rows.
A more complex metadata dispatch LFB may be defined in future version A more complex metadata dispatch LFB may be defined in future version
of the library. In that LFB, multiple tuples of metadata may be of the library. In that LFB, multiple tuples of metadata may be
adopted to dispatch packets. adopted to dispatch packets.
5.5.1.2. Components
This LFB has only one component named MetadataDispatchTable which is
defined as an array. Each row of the array is a struct containing a
Metadata ID, a Metadata value and the OutputIndex to selectt the
output port from the group.
5.5.1.3. Capabilities
This LFB does not have a list of capabilities
5.5.1.4. Events
This LFB does not have any events specified.
5.5.2. GenericScheduler 5.5.2. GenericScheduler
This is a preliminary generic scheduler LFB for abstracting a simple
scheduling process.
5.5.2.1. Data Handling
There exist various kinds of scheduling strategies with various There exist various kinds of scheduling strategies with various
implementations. As a base LFB library, this document only defines a implementations. As a base LFB library, this document only defines a
preliminary generic scheduler LFB for abstracting a simple scheduling preliminary generic scheduler LFB for abstracting a simple scheduling
process. The generic scheduler LFB is the one. Users may use this process. Users may use this LFB as a basic scheduler LFB to further
LFB as a basic scheduler LFB to further construct more complex construct more complex scheduler LFBs by means of inheritance as
scheduler LFBs by means of inheritance as described in RFC 5812 described in RFC 5812 [RFC5812].
[RFC5812].
The LFB describes scheduling process in the following model: Packets of any arbitrary frame type are received via a group input
known as "PktsIn" with no additional metadata expected. This group
input is capable of multiple input port instances. Each port
instance may be connected to different upstream LFB output.
o It is with a group input and expects packets with arbitrary frame Multiple queues reside at the input side, with every input port
types to arrive for scheduling. The group input is capable of instance connected to one queue. Every queue is marked with a queue
multiple input port instances. Each port instance may be ID, and the queue ID is exactly the same as the index of
connected to different upstream LFB output. No metadata is corresponding input port instance. Scheduling disciplines are
expected for each input packet. applied to all queues and also all packets in the queues.
o Multiple queues reside at the input side, with every input port Scheduled packets are output from a singleton output port of the LFB
instance connected to one queue. knows as "PktsOut" with no corresponding metadata.
o Every queue is marked with a queue ID, and the queue ID is exactly More complex scheduler LFBs may be defined with more complex
the same as the index of corresponding input port instance. scheduling disciplines by succeeding this LFB. For instance, a
priority scheduler LFB may be defined only by inheriting this LFB and
defining a component to indicate priorities for all input queues.
o Scheduling disciplines are applied to all queues and also all 5.5.2.2. Components
packets in the queues.
o Scheduled packets are output from a singleton output port of the The QueueCount component is defined to specify the number of queues
LFB. to be scheduled.
Two LFB components are defined to further describe above model. A The SchedulingDiscipline component is for the CE to specify a
scheduling discipline component is defined for CE to specify a
scheduling discipline to the LFB. Currently defined scheduling scheduling discipline to the LFB. Currently defined scheduling
disciplines only include FIFO and round robin(RR). For FIFO, we disciplines only include FIFO and Round Robin (RR). When a FIFO
limit above model that when a FIFO discipline is applied, it is discipline is applied, it is requires that there is only one input
require that there is only one input port instance for the group port instance for the group input. If the user accidentally defines
input. If user accidentally defines multiple input port instances multiple input port instances for FIFO scheduling, only packets in
for FIFO scheduling, only packets in the input port with lowest port the input port with lowest port index will be scheduled to output
index will be scheduled to output port, and all packets in other port, and all packets in other input port instances will just
input port instances will just ignored. ignored. Note that if the generic scheduler LFB is defined only one
We specify that if the generic scheduler LFB is defined only one
input port instance, the default scheduling discipline is FIFO. If input port instance, the default scheduling discipline is FIFO. If
the LFB is defined with more than one input port instances, the the LFB is defined with more than one input port instances, the
default scheduling discipline is round robin (RR). default scheduling discipline is round robin (RR).
A current queue depth component is defined to allow CE to query every The CurrentQueueDepth component is defined to allow CE to query every
queue status of the scheduler. Using the queue ID as the index, CE queue status of the scheduler. It is an array component and each row
can query every queue for its used length in unit of packets or of the array is a struct containing a queue ID, the queue depth in
bytes. packets and the queue depth in bytes. Using the queue ID as the
index, the CE can query every queue for its used length in unit of
packets or bytes.
Several capabilities are defined for the LFB. A queue number limit 5.5.2.3. Capabilities
is defined which limits the scheduler maximum supported queue number,
which is also the maximum number of input port instances. Capability
of disciplines supported provides scheduling discipline types
supported by the FE to CE. Queue length limit provides the
capability of storage ability for every queue.
More complex scheduler LFB may be defined with more complex Three capabilities are currently defined for the GenericScheduler.
scheduling discipline by succeeding this LFB. For instance, a
priority scheduler LFB may be defined only by inheriting this LFB and
define a component to indicate priorities for all input queues.
See Section 6 for detailed XML definition for this LFB. o A queue number limit, which specify the limit of the maximum
supported number of queues, which is also the maximum number of
input port instances.
o The supported scheduling disciplines types by the FE, currently
maximum 6.
o The queue length limit providing the storage ability for every
queue.
5.5.2.4. Events
This LFB does not have any events specified.
6. XML for LFB Library 6. XML for LFB Library
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseLFBLibrary"> provides="BaseLFBLibrary">
<load library="BaseTypeLibrary"/> <load library="BaseTypeLibrary"/>
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="3"> <LFBClassDef LFBClassID="3">
<name>EtherPHYCop</name> <name>EtherPHYCop</name>
<synopsis>The LFB describes an Ethernet port abstracted at <synopsis>The LFB describes an Ethernet port abstracted at
physical layer.It limits its physical media to copper. physical layer.It limits its physical media to copper.
Multiple virtual PHYs isn't supported in this LFB version. Multiple virtual PHYs isn't supported in this LFB version.
skipping to change at page 64, line 36 skipping to change at page 70, line 36
<typeRef>VlanInputTableType</typeRef> <typeRef>VlanInputTableType</typeRef>
</component> </component>
<component access="read-reset" componentID="3"> <component access="read-reset" componentID="3">
<name>EtherClassifyStats</name> <name>EtherClassifyStats</name>
<synopsis>Ether classify statistic table</synopsis> <synopsis>Ether classify statistic table</synopsis>
<typeRef>EtherClassifyStatsTableType</typeRef> <typeRef>EtherClassifyStatsTableType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="6"> <LFBClassDef LFBClassID="6">
<name>EtherEncapsulator</name> <name>EtherEncap</name>
<synopsis>This LFB abstracts the process to encapsulate IP <synopsis>This LFB abstracts the process to encapsulate IP
packets to Ethernet packets according to the L2 information. packets to Ethernet packets according to the L2 information.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>EncapIn</name> <name>EncapIn</name>
<synopsis>A Single Packet Input</synopsis> <synopsis>A Single Packet Input</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
skipping to change at page 68, line 49 skipping to change at page 74, line 50
<ref>ValidateErrorID</ref> <ref>ValidateErrorID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component access="read-write" componentID="1"> <component access="read-write" componentID="1">
<name>IPv4ValidatorStats</name> <name>IPv4ValidatorStats</name>
<synopsis>IPv4 validator statistics information. <synopsis>IPv4 validator statistics information.
</synopsis> </synopsis>
<typeRef>IPv4ValidatorStatisticsType</typeRef> <typeRef>IPv4ValidatorStatsType</typeRef>
</component> </component>
</components>
</components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="9"> <LFBClassDef LFBClassID="9">
<name>IPv6Validator</name> <name>IPv6Validator</name>
<synopsis>An LFB that performs IPv6 packets validation <synopsis>An LFB that performs IPv6 packets validation
according to RFC2460. At the same time, ipv6 unicast and according to RFC2460. At the same time, ipv6 unicast and
multicast are classified in this LFB.</synopsis> multicast are classified in this LFB.</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>ValidatePktsIn</name> <name>ValidatePktsIn</name>
skipping to change at page 69, line 52 skipping to change at page 76, line 4
<outputPort> <outputPort>
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis>Output for exception packet.</synopsis> <synopsis>Output for exception packet.</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product>
</product>
</outputPort> </outputPort>
<outputPort> <outputPort>
<name>FailOut</name> <name>FailOut</name>
<synopsis>Output for failed validation packet. <synopsis>Output for failed validation packet.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ValidateErrorID</ref> <ref>ValidateErrorID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component access="read-write" componentID="1"> <component access="read-write" componentID="1">
<name>IPv6ValidatorStats</name> <name>IPv6ValidatorStats</name>
<synopsis>IPv6 validator statistics information. <synopsis>IPv6 validator statistics information.
</synopsis> </synopsis>
<typeRef>IPv6ValidatorStatisticsType</typeRef> <typeRef>IPv6ValidatorStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="10"> <LFBClassDef LFBClassID="10">
<name>IPv4UcastLPM </name> <name>IPv4UcastLPM </name>
<synopsis>An LFB that performs IPv4 Longest Prefix Match <synopsis>An LFB that performs IPv4 Longest Prefix Match
Lookup.It is defined to provide some facilities to support Lookup.It is defined to provide some facilities to support
users to implement equal-cost multi-path routing(ECMP) or users to implement equal-cost multi-path routing(ECMP) or
reverse path forwarding (RPF).</synopsis> reverse path forwarding (RPF).</synopsis>
<version>1.0</version> <version>1.0</version>
skipping to change at page 71, line 51 skipping to change at page 78, line 4
<name>IPv4PrefixTable</name> <name>IPv4PrefixTable</name>
<synopsis>The IPv4 prefix table.</synopsis> <synopsis>The IPv4 prefix table.</synopsis>
<typeRef>IPv4PrefixTableType</typeRef> <typeRef>IPv4PrefixTableType</typeRef>
</component> </component>
<component componentID="2" access="read-reset"> <component componentID="2" access="read-reset">
<name>IPv4UcastLPMStats</name> <name>IPv4UcastLPMStats</name>
<synopsis>Statistics for IPv4 Unicast Longest Prefix <synopsis>Statistics for IPv4 Unicast Longest Prefix
Match</synopsis> Match</synopsis>
<typeRef>IPv4UcastLPMStatsType</typeRef> <typeRef>IPv4UcastLPMStatsType</typeRef>
</component> </component>
</components>
</components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="11"> <LFBClassDef LFBClassID="11">
<name>IPv6UcastLPM </name> <name>IPv6UcastLPM </name>
<synopsis>An LFB that performs IPv6 Longest Prefix Match <synopsis>An LFB that performs IPv6 Longest Prefix Match
Lookup.It is defined to provide some facilities to support Lookup.It is defined to provide some facilities to support
users to implement equal-cost multi-path routing(ECMP) or users to implement equal-cost multi-path routing(ECMP) or
reverse path forwarding (RPF).</synopsis> reverse path forwarding (RPF).</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
skipping to change at page 74, line 14 skipping to change at page 80, line 16
<outputPorts> <outputPorts>
<outputPort group="true"> <outputPort group="true">
<name>SuccessOut</name> <name>SuccessOut</name>
<synopsis>The output for the packet if it is valid to be <synopsis>The output for the packet if it is valid to be
forwarded</synopsis> forwarded</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>OutputLogicalPortID</ref> <ref>L3PortID</ref>
<ref>NextHopIPv4Addr</ref> <ref>NextHopIPv4Addr</ref>
<ref availability="conditional">
MediaEncapInfoIndex</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis>The output for the packet if an exception <synopsis>The output for the packet if an exception
occurs</synopsis> occurs</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
skipping to change at page 75, line 25 skipping to change at page 81, line 28
<outputPorts> <outputPorts>
<outputPort group="true"> <outputPort group="true">
<name>SuccessOut</name> <name>SuccessOut</name>
<synopsis>The output for the packet if it is valid to <synopsis>The output for the packet if it is valid to
be forwarded</synopsis> be forwarded</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>OutputLogicalPortID</ref> <ref>L3PortID</ref>
<ref>NextHopIPv6Addr</ref> <ref>NextHopIPv6Addr</ref>
<ref availability="conditional">
MediaEncapInfoIndex</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis>The output for the packet if an exception <synopsis>The output for the packet if an exception
occurs</synopsis> occurs</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
skipping to change at page 80, line 7 skipping to change at page 86, line 7
<typeRef>SchdDisciplineType</typeRef> <typeRef>SchdDisciplineType</typeRef>
</array> </array>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
</LFBClassDefs> </LFBClassDefs>
</LFBLibrary> </LFBLibrary>
7. LFB Class Use Cases 7. LFB Class Use Cases
This section demonstrates examples on how the LFB classes defined by This section demonstrates examples on how the LFB classes defined by
the Base LFB library in Section 6 are applied to achieve typical the Base LFB library in Section 6 are applied to achieve some typical
router functions. router functions. The functions to demonstrate are:
As mentioned in the overview section, typical router functions can be
categorized in short into the following functions:
o IP forwarding
o address resolution
o ICMP
o network management o IPv4 forwarding
o running routing protocol o ARP processing
To achieve the functions, processing paths organized by the LFB To achieve the functions, processing paths organized by the LFB
classes with their interconnections should be established in FE. In classes with their interconnections should be established in FE. In
general, CE controls and manages the processing paths by use of the general, CE controls and manages the processing paths by use of the
ForCES protocol. ForCES protocol.
Note that LFB class use cases shown in this section are only as Note that LFB class use cases shown in this section are only as
examples to demonstrate how typical router functions can be examples to demonstrate how typical router functions are able to be
implemented with the defined base LFB library. Users and implemented with the defined base LFB library. Users and
implementers should not be limited by the examples. implementers should not be limited by the example use cases.
7.1. IP Forwarding 7.1. IPv4 Forwarding
TBD Figure 1 (Section 3.2.3) shows a normal IPv4 forwarding processing
path by use of the base LFB classes. To make it in focus, LFB
classes that are not close to IPv4 forwarding function are ignored in
the figure. Moreover, inputs or outputs of some LFBs that are not
related to IP forwarding are also ignored in the LFB figure.
In the example case, network interfaces are limited to copper
Ethernet ports. A number of EtherPHYCop LFBs are used to describe
physical layer functions of the ports. An EtherMACIn LFB follows
every EtherPHYCop LFB to describe the MAC layer processing. A
PHYPortID metadatum is generated by EtherPHYCop LFB and will be used
by all the following LFBs. In EtherMACIn LFB, a locality check of
MAC addresses may be performed if CE asks to do so by configuring the
LFB component.
Ethernet packets out of the EtherMACIn LFB are sent to an
EtherClassifier LFB to be decapsulated and classified into network
layer types like IPv4, IPv6, ARP, etc. In the example case, every
physical Ethernet interface is associated with one Classifier
instance, whereas it is also practical that all physical interfaces
are associated with only one Ethernet Classifier instance.
EtherClassifier will use PHYPortID and Ethernet type of the input
packet and VlanID, if exists in the input Ethernet packets, to decide
the packet network layer type and its output port from this LFB, and
also to assign a new logical port ID to the packet for later use. At
the same time, the LFB also generate some new metadata for every
packet like EtherType, SrcMAC, DstMAC, LogicPortID, etc for later
LFBs to use.
If a packet is classified as an IPv4 packet, it will be sent to an
IPv4Validator LFB to validate the IPv4 packet. In the validator LFB,
IPv4 packets will be classified into IPv4 unicast packets and
multicast packets, as well as validating the IPv4 packets.
IPv4 unicast packets will be sent to IPv4UcastLPM LFB, where LPM is
made and a next hop ID is achieved. The packet with the next hop ID
is further sent to an IPv4NextHop LFB, where further next hop
information is found for this packet. The information includes where
the packet is to go next and even the media encapsulation type for
the port, etc. An L3PortID is used to identify a next hop output
port, which is represented as a metadatum associated with the packet
to be forwarded to via port. In the example case, the next hop
output port is an Ethernet type. As a result, the packet and its L3
port ID metadatum are sent to an EtherEncap LFB, where the packet is
encapsulated as an Ethernet packet. A BasicMetadataDispatch LFB
follows the EtherEncap LFB where packets will be dispatched to
different output port according to the L3PortID metadatum sent to the
LFB. As a result, IPv4 packets are forwarded out via various output
ports.
7.2. ARP processing
Figure 2 shows the processing path for ARP protocol in the case that
there is no specific ARP processing LFBs in FE. In such case, CE
should implement the ARP processing function. As usual, to make it
in focus, the figure ignores LFB classes that are not related to ARP
processing. The figure also ignores some inputs or outputs of LFBs
that are out of the scope of ARP processing.
The example case still takes Ethernet ports as its network
interfaces.
+---+ +---+
| | ARP packets | |
| |------------------------+--->| | To CE
...-->| | . | | |
| | . | +---+
| | . | RedirectOut
+---+ |
Ether EtherEncap | IPv4 packets lack
Classifier +---+ | address resolution information
| | |
Packets need | |--------->---+
...--------->| |
L2 Encapsulation| |
+---+ | | +------+
| | +-->| |--+ +---+ |Ether |
| | | +---+ | | |--------->|MACOut|-->...
From CE| |--+ +-->| | . +------+
| |ARP Packets | | .
| |from CE | | . +------+
| | | |--------> |Ether |-->...
+---+ +---+ |MACOut|
RedirectIn BasicMetadata +------+
Dispatch
Figure 2: LFB use case for ARP
As the figure shows, ARP protocol packets from network interfaces can
be filtered out by EtherClassifier LFB. In the example case, we
presume the FE does not provide ability for ARP processing and relies
on CE to do the work. Hence, the classified ARP packets and some
associated metadata are then sent to RedirectOut LFB so as to be
transported to CE. CE can then process the received APR packets to
get information to establish ARP tables. While it depends on
individual implementations how this is implemented and is out of the
scope of ForCES
When CE deploys ARP function, it may need to generate ARP request or
response packets and send them back to outer networks. To do so, the
packets are redirected to FE through a RedirectIn LFB first. Then,
just like to forward IPv4 packets, the ARP packets are also
encapsulated to Ethernet format by an EtherEncap LFB, and then
dispatched to different interfaces via a BasicMetadataDispatch LFB.
The BasicMetadataDispatch LFB will dispatch the packets according to
the L3PortID metadatum included in every ARP packet sent from CE.
The EtherEncap LFB also receives packets that need Ethernet L2
encapsulating. If the encapsulator finds that it can not fulfill
encapsulating some packets because of lack of L2 Ethernet information
for the packets, the LFB will output the packets from the
ExceptionOut output of the LFB. By connecting this output to
RedirectOut LFB, the packets can be redirected to CE for further ARP
processing. See Section 5.1.4 for details. CE may then generate ARP
requests based on the packets, and redirect ARP request messages to
FE to send to networks, just as the procedure shown above.
With these mechanisms and procedures, ARP function is expected to be
implemented by CE with the help from FE.
8. Contributors 8. Contributors
The authors would like to thank Jamal Hadi Salim, Ligang Dong, and The authors would like to thank Jamal Hadi Salim, Ligang Dong, and
Fenggen Jia who made major contributions to the development of this Fenggen Jia who made major contributions to the development of this
document. document.
Jamal Hadi Salim Jamal Hadi Salim
Mojatatu Networks Mojatatu Networks
Ottawa, Ontario Ottawa, Ontario
skipping to change at page 83, line 7 skipping to change at page 92, line 7
P.R.China P.R.China
EMail: jfg@mail.ndsc.com.cn EMail: jfg@mail.ndsc.com.cn
9. Acknowledgements 9. Acknowledgements
This document is based on earlier documents from Joel Halpern, Ligang This document is based on earlier documents from Joel Halpern, Ligang
Dong, Fenggen Jia and Weiming Wang. Dong, Fenggen Jia and Weiming Wang.
10. IANA Considerations 10. IANA Considerations
(TBD) IANA has created a registry of ForCES LFB Class Names and the
corresponding ForCES LFB Class Identifiers, with the location of the
definition of the ForCES LFB Class, in accordance with the rules to
use the namespace.
The LFB library in this document needs for unique class names and
numeric class identifiers of all LFBs. Besides, this document also
needs to define the following namespaces:
o Metadata ID, defined in Section 4.3 and Section 4.4
o Exception ID, defined in Section 4.4
o Validate Error ID, defined in Section 4.4
10.1. LFB Class Names and LFB Class Identifiers
LFB classes defined by this document belongs to IETF defined LFBs by
Standard Track RFCs. According to IANA, the identifier namespace for
these LFB classes is from 3 to 65535.
The assignment of LFB class names and LFB class identifiers is as in
the following table.
+-----------+---------------+------------------------+--------------+
| LFB Class | LFB Class Name| Description | Reference |
| Identifier| | | |
+-----------+---------------+------------------------+--------------+
| 3 | EtherPHYCop | Define an Ethernet port| RFC????(this|
| | | abstracted at physical | document) |
| | | layer | Section 5.1.1|
| | | -------------- | |
| 4 | EtherMACIn | Define an Ethernet | RFC???? |
| | | input port at MAC data | Section 5.1.2|
| | | link layer | |
| | | -------------- | |
| 5 |EtherClassifier| Define the process to | RFC???? |
| | | decapsulate Ethernet | Section 5.1.3|
| | | packets and classify | |
| | | the packets | |
| | | -------------- | |
| 6 | EtherEncap | Define the process to | RFC???? |
| | | encapsulate IP packets | Section 5.1.4|
| | | to Ethernet packets | |
| | | -------------- | |
| 7 | EtherMACOut | Define an Ethernet | RFC ???? |
| | | output port at MAC | Section 5.1.5|
| | | data link layer | |
| | | -------------- | |
| 8 | IPv4Validator | Perform IPv4 packets | RFC ???? |
| | | validation. | Section 5.2.1|
| | | -------------- | |
| 9 | IPv6Validator | Perform IPv6 packets | RFC ???? |
| | | validation | Section 5.2.2|
| | | -------------- | |
| 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? |
| | | Prefix Match Lookup | Section 5.3.1|
| | | -------------- | |
| 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC ???? |
| | | Prefix Match Lookup | Section 5.3.3|
| | | -------------- | |
| 12 | IPv4NextHop | Define the process of | RFC ??? |
| | | selecting Ipv4 next hop| Section 5.3.2|
| | | action | |
| | | -------------- | |
| 13 | IPv6NextHop | Define the process of | RFC ??? |
| | | selecting Ipv6 next hop| Section 5.3.4|
| | | action | |
| | | -------------- | |
| 14 | RedirectIn | Define the process for | RFC ??? |
| | | CE to inject data | Section 5.4.1|
| | | packets into FE LFB | |
| | | topology | |
| | | -------------- | |
| 15 | RedirectOut | Define the process for | RFC ??? |
| | | LFBs in FE to deliver | Section 5.4.2|
| | | data packets to CE | |
| | | -------------- | |
| 16 |BasicMetadata | Dispatch input packets | RFC ??? |
| |Dispatch | to a group output | Section 5.5.1|
| | | according to a metadata| |
| | | -------------- | |
| 17 |Generic | Define a preliminary | RFC ???? |
| |Scheduler | generic scheduling | Section 5.5.2|
| | | process | |
+-----------+---------------+------------------------+--------------+
Table 1
10.2. Metadata ID
The Metadata ID namespace is 32 bits long. The following is the
guideline for managing the namespace.
Metadata ID 0x00000000-0x7FFFFFFF
Metadata with IDs in this range are Specification Required
[RFC5226]. A metadata ID using this range MUST be documented in
an RFC or other permanent and readily available references.
Values assigned by this specification:
+--------------+-------------------------+--------------------------+
| Value | Name | Definition |
+--------------+-------------------------+--------------------------+
| 0x00000001 | EtherPHYCop | See Section 4.4 |
| 0x00000002 | SrcMAC | See Section 4.4 |
| 0x00000003 | DstMAC | See Section 4.4 |
| 0x00000004 | LogicalPortID | See Section 4.4 |
| 0x00000005 | EtherType | See Section 4.4 |
| 0x00000006 | VlanID | See Section 4.4 |
| 0x00000007 | VlanPriority | See Section 4.4 |
| 0x00000008 | NexthopIPv4Addr | See Section 4.4 |
| 0x00000009 | NexthopIPv6Addr | See Section 4.4 |
| 0x0000000A | HopSelector | See Section 4.4 |
| 0x0000000B | ExceptionID | See Section 4.4 |
| 0x0000000C | ValidateErrorID | See Section 4.4 |
| 0x0000000D | L3PortID | See Section 4.4 |
| 0x0000000E | RedirectIndex | See Section 4.4 |
| 0x0000000F | MediaEncapInfoIndex | See Section 4.4 |
+--------------+-------------------------+--------------------------+
Table 2
Metadata ID 0x80000000-0xFFFFFFFFF
Metadata IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals.
10.3. Exception ID
The Exception ID namespace is 32 bits long. The following is the
guideline for managing the namespace.
Exception ID 0x00000000-0x7FFFFFFF
Exception IDs in this range are Specification Required [RFC5226].
An exception ID using this range MUST be documented in an RFC or
other permanent and readily available references.
Values assigned by this specification:
+--------------+---------------------------------+------------------+
| Value | Name | Definition |
+--------------+---------------------------------+------------------+
| 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 |
| 0x00000001 | BroadCastPacket | See Section 4.4 |
| 0x00000002 | BadTTL | See Section 4.4 |
| 0x00000003 | IPv4HeaderLengthMismatch | See Section 4.4 |
| 0x00000004 | LengthMismatch | See Section 4.4 |
| 0x00000005 | RouterAlertOptions | See Section 4.4 |
| 0x00000006 | RouteInTableNotFound | See Section 4.4 |
| 0x00000007 | NextHopInvalid | See Section 4.4 |
| 0x00000008 | FragRequired | See Section 4.4 |
| 0x00000009 | LocalDelivery | See Section 4.4 |
| 0x0000000A | GenerateICMP | See Section 4.4 |
| 0x0000000B | PrefixIndexInvalid | See Section 4.4 |
| 0x0000000C | IPv6HopLimitZero | See Section 4.4 |
| 0x0000000D | IPv6NextHeaderHBH | See Section 4.4 |
+--------------+---------------------------------+------------------+
Table 3
Exception ID 0x80000000-0xFFFFFFFFF
Exception IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals.
10.4. Validate Error ID
The Validate Error ID namespace is 32 bits long. The following is
the guideline for managing the namespace.
Validate Error ID 0x00000000-0x7FFFFFFF
Validate Error IDs in this range are Specification Required
[RFC5226]. A Validate Error ID using this range MUST be
documented in an RFC or other permanent and readily available
references.
Values assigned by this specification:
+--------------+---------------------------------+------------------+
| Value | Name | Definition |
+--------------+---------------------------------+------------------+
| 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 |
| 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 |
| 0x00000002 | NotIPv4Packet | See Section 4.4 |
| 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 |
| 0x00000004 | InvalidIPv4Checksum | See Section 4.4 |
| 0x00000005 | InvalidIPv4SrcAddrCase1 | See Section 4.4 |
| 0x00000006 | InvalidIPv4SrcAddrCase2 | See Section 4.4 |
| 0x00000007 | InvalidIPv4SrcAddrCase3 | See Section 4.4 |
| 0x00000008 | InvalidIPv4SrcAddrCase4 | See Section 4.4 |
| 0x00000009 | InvalidIPv6PakcetSize | See Section 4.4 |
| 0x0000000A | NotIPv6Packet | See Section 4.4 |
| 0x0000000B | InvalidIPv6SrcAddrCase1 | See Section 4.4 |
| 0x0000000C | InvalidIPv6SrcAddrCase2 | See Section 4.4 |
| 0x0000000D | InvalidIPv6DstAddrCase1 | See Section 4.4 |
+--------------+---------------------------------+------------------+
Table 4
Validate Error ID 0x80000000-0xFFFFFFFFF
Validate Error IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals.
11. Security Considerations 11. Security Considerations
These definitions if used by an FE to support ForCES create The ForCES framework document [RFC3746] provides a comprehensive
manipulable entities on the FE. Manipulation of such objects can security analysis for the overall ForCES architecture. For example,
produce almost unlimited effects on the FE. FEs should ensure that the ForCES protocol entities must be authenticated per the ForCES
only properly authenticated ForCES protocol participants are requirements before they can access the information elements
performing such manipulations. Thus the security issues with this described in this document via ForCES. Access to the information
protocol are defined in the ForCES protocol [RFC5810]. contained in this document is accomplished via the ForCES
protocol[RFC5810], which is defined in separate documents, and thus
the security issues will be addressed there.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010. Specification", RFC 5810, March 2010.
 End of changes. 210 change blocks. 
673 lines changed or deleted 1246 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/