draft-ietf-forces-lfb-lib-11.txt   draft-ietf-forces-lfb-lib-12.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: September 16, 2013 University of Patras Expires: September 30, 2013 University of Patras
K. Ogawa K. Ogawa
NTT Corporation NTT Corporation
C. Li C. Li
Hangzhou DPtech Hangzhou DPtech
J. Halpern J. Halpern
Ericsson Ericsson
March 15, 2013 March 29, 2013
ForCES Logical Function Block (LFB) Library ForCES Logical Function Block (LFB) Library
draft-ietf-forces-lfb-lib-11 draft-ietf-forces-lfb-lib-12
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). The used in the Forwarding and Control Element Separation (ForCES). The
basic LFB classes are defined according to ForCES FE model and ForCES basic LFB classes are defined according to ForCES FE model and ForCES
protocol specifications, and are scoped to meet requirements of protocol specifications, and are scoped to meet requirements of
typical router functions and considered as the basic LFB library for typical router functions and considered as the basic LFB library for
ForCES. The library includes the descriptions of the LFBs and the ForCES. The library includes the descriptions of the LFBs and the
XML definitions. XML definitions.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 September 16, 2013. This Internet-Draft will expire on September 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 43 skipping to change at page 2, line 43
4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 16 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 16
4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 17 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 17
5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 43 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 43
5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 43 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 43
5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 44 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 44
5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 46 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 46
5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 48 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 48
5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 50 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 50
5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 52 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 52
5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 53 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 53
5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 53 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 54
5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55
5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 57 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 57
5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 57 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 57
5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 59 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 59
5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 61 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 61
5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 63 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 63
5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 65 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 65
5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 65 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 65
5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 66 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 66
5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 67 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 67
skipping to change at page 3, line 23 skipping to change at page 3, line 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 107 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 107
10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 109 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 109
10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 109 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 109
10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 110 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 110
11. Security Considerations . . . . . . . . . . . . . . . . . . . 112 11. Security Considerations . . . . . . . . . . . . . . . . . . . 112
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
12.1. Normative References . . . . . . . . . . . . . . . . . . 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 113
12.2. Informative References . . . . . . . . . . . . . . . . . 113 12.2. Informative References . . . . . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115
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 6, line 41 skipping to change at page 6, line 41
forwarding plane inside an FE. Note that more than one data path forwarding plane inside an FE. Note that more than one data path
can exist within an FE. can exist within an FE.
ForCES Protocol - While there may be multiple protocols used ForCES Protocol - While there may be multiple protocols used
within the overall ForCES architecture, the term "ForCES protocol" within the overall ForCES architecture, the term "ForCES protocol"
and "protocol" refer to the Fp reference points in the ForCES and "protocol" refer to the Fp reference points in the ForCES
Framework in [RFC3746]. This protocol does not apply to CE-to-CE Framework in [RFC3746]. This protocol does not apply to CE-to-CE
communication, FE-to-FE communication, or to communication between communication, FE-to-FE communication, or to communication between
FE and CE managers. Basically, the ForCES protocol works in a FE and CE managers. Basically, the ForCES protocol works in a
master-slave mode in which FEs are slaves and CEs are masters. master-slave mode in which FEs are slaves and CEs are masters.
This document defines the specifications for this ForCES protocol.
LFB Port - A port refers to an LFB input port or output port. See
Section 3.2 of [RFC5812] for more detailed definitions.
Physical Port - A port refers to a physical media input port or Physical Port - A port refers to a physical media input port or
output port of an FE. A physical port is usually assigned with a output port of an FE. A physical port is usually assigned with a
physical port ID, abbreviated with a PHYPortID. This document physical port ID, abbreviated with a PHYPortID. This document
mainly deals with physical ports with Ethernet media. mainly deals with physical ports with Ethernet media.
Logical Port - A conceptually virtual port at data link layer (L2) Logical Port - A conceptually virtual port at data link layer (L2)
or network layer (L3). A logical port is usually assigned with a or network layer (L3). A logical port is usually assigned with a
logical port ID, abbreviated with a LogicalPortID. The logical logical port ID, abbreviated with a LogicalPortID. The logical
ports can be further categorized with a L2 logical port or a L3 ports can be further categorized with a L2 logical port or a L3
logical port. An L2 logical port can be assigned with a L2 logical port. An L2 logical port can be assigned with a L2
logical port ID, abbreviated with a L2PortID. An L3 logical port logical port ID, abbreviated with a L2PortID. An L3 logical port
can be assigned with a L3 logical port ID, abbreviated with a can be assigned with a L3 logical port ID, abbreviated with a
L3PortID. MAC layer VLAN ports belongs to L2 logical ports as L3PortID. MAC layer VLAN ports belongs to L2 logical ports as
well as logical ports. well as logical ports.
LFB Port - The connection points where one LFB can be connected to
another within an FE. As described in [RFC5812], the CE can
connect LFBs together by establishing connections between an
output port of one LFB instance and an input port of another LFB
instance. Also see Section 3.2 of [RFC5812] for more details.
Singleton Port - A named input or output port of an LFB. This
port is referred to by a name. When the context is clear, the
term singleton by itself is used to refer to a singleton port.
Group Port - A named collection of input or output ports of an
LFB. A group port is referred to by a name. Whereas, a group
port consists of a number of port instances, which are referred to
by a combination of a name and an index.
LFB Class Library - The LFB class library is a set of LFB classes LFB Class Library - The LFB class library is a set of LFB classes
that has been identified as the most common functions found in that has been identified as the most common functions found in
most FEs and hence should be defined first by the ForCES Working most FEs and hence should be defined first by the ForCES Working
Group. The LFB Class Library is defined by this document. Group. The LFB Class Library is defined by this document.
3. Introduction 3. Introduction
[RFC5810] specifies Forwarding and Control Element Separation [RFC3746] specifies Forwarding and Control Element Separation
(ForCES) framework. In the framework, Control Elements (CEs) (ForCES) framework. In the framework, Control Elements (CEs)
configure and manage one or more separate Forwarding Elements (FEs) configure and manage one or more separate Forwarding Elements (FEs)
within a Network Element (NE) by use of a ForCES protocol. [RFC5810] within a Network Element (NE) by use of a ForCES protocol. [RFC5810]
specifies the ForCES protocol. [RFC5812] specifies the Forwarding specifies the ForCES protocol. [RFC5812] specifies the Forwarding
Element (FE) model. In the model, resources in FEs are described by Element (FE) model. In the model, resources in FEs are described by
classes of Logical Function Blocks (LFBs). The FE model defines the classes of Logical Function Blocks (LFBs). The FE model defines the
structure and abstract semantics of LFBs, and provides XML schema for structure and abstract semantics of LFBs, and provides XML schema for
the definitions of LFBs. the definitions of LFBs.
This document conforms to the specifications of the FE model This document conforms to the specifications of the FE model
skipping to change at page 9, line 22 skipping to change at page 9, line 22
(3) Receive and forward Internet datagrams. Important issues in (3) Receive and forward Internet datagrams. Important issues in
this process are buffer management, congestion control, and this process are buffer management, congestion control, and
fairness. fairness.
* Recognizes error conditions and generates ICMP error and * Recognizes error conditions and generates ICMP error and
information messages as required. information messages as required.
* Drops datagrams whose time-to-live fields have reached zero. * Drops datagrams whose time-to-live fields have reached zero.
* Fragments datagrams when necessary to fit into the MTU of the * Fragments datagrams when necessary to fit into the MTU of the
next network. next link or interface.
(4) Choose a next hop destination for each IP datagram, based on the (4) Choose a next hop destination for each IP datagram, based on the
information in its routing database. information in its routing database.
(5) Usually support an interior gateway protocol (IGP) to carry out (5) Usually support an interior gateway protocol (IGP) to carry out
distributed routing and reachability algorithms with the other distributed routing and reachability algorithms with the other
routers in the same autonomous system. In addition, some routers in the same autonomous system. In addition, some
routers will need to support an exterior gateway protocol (EGP) routers will need to support an exterior gateway protocol (EGP)
to exchange topological information with other autonomous to exchange topological information with other autonomous
systems. For all routers, it is essential to provide ability to systems. For all routers, it is essential to provide ability to
skipping to change at page 14, line 41 skipping to change at page 14, line 41
To define a base LFB library for typical router functions, a set of To define a base LFB library for typical router functions, a set of
base data types, frame types, and metadata types should be defined. base data types, frame types, and metadata types should be defined.
This section provides a brief description of the base types and a This section provides a brief description of the base types and a
full XML definition of them as well. full XML definition of them as well.
The base type XML definitions are provided with a separate XML The base type XML definitions are provided with a separate XML
library file named "BaseTypeLibrary". Users can refer to this library file named "BaseTypeLibrary". Users can refer to this
library by the statement: library by the statement:
<load library="BaseTypeLibrary", location="..."/> <load library="BaseTypeLibrary" location="..."/>
4.1. Data Types 4.1. Data Types
Data types defined in the base type library are categorized by types Data types defined in the base type library are categorized by types
of atomic, compound struct, and compound array. of atomic, compound struct, and compound array.
4.1.1. Atomic 4.1.1. Atomic
The following data types are defined as atomic data types and put in The following data types are defined as atomic data types and put in
the base type library: the base type library:
skipping to change at page 46, line 51 skipping to change at page 46, line 51
output packets exactly the same as that in the NormalPathOut output. output packets exactly the same as that in the NormalPathOut output.
This LFB can be set to work in a Promiscuous Mode, allowing all This LFB can be set to work in a Promiscuous Mode, allowing all
packets to pass through the LFB without being dropped. Otherwise, a packets to pass through the LFB without being dropped. Otherwise, a
locality check will be performed based on the local MAC addresses. locality check will be performed based on the local MAC addresses.
All packets that do not pass through the locality check will be All packets that do not pass through the locality check will be
dropped. dropped.
This LFB can optionally participate in Ethernet flow control in This LFB can optionally participate in Ethernet flow control in
cooperation with EtherMACOut LFB. This document does not go into the cooperation with EtherMACOut LFB. This document does not go into the
details of how this is implemented; the reader may refer to some details of how this is implemented. This document also does not
relevant references. This document also does not describe how the describe how the buffers which induce the flow control messages
buffers which induce the flow control messages behave - it is assumed behave - it is assumed that such artifacts exist and describing them
that such artifacts exist and describing them is out of scope in this is out of scope in this document.
document.
5.1.2.2. Components 5.1.2.2. Components
The AdminStatus component is defined for the CE to administratively The AdminStatus component is defined for the CE to administratively
manage the status of the LFB. The CE may administratively startup or manage the status of the LFB. The CE may administratively startup or
shutdown the LFB by changing the value of AdminStatus. The default shutdown the LFB by changing the value of AdminStatus. The default
value is set to 'Down'. value is set to 'Down'.
The LocalMACAddresses component specifies the local MAC addresses The LocalMACAddresses component specifies the local MAC addresses
based on which locality checks will be made. This component is an based on which locality checks will be made. This component is an
array of MAC addresses, and of 'read-write' access permission. array of MAC addresses, and of 'read-write' access permission.
An L2BridgingPathEnable component captures whether the LFB is set to An L2BridgingPathEnable component captures whether the LFB is set to
work as a L2 bridge. An FE that does not support bridging will work as a L2 bridge. An FE that does not support bridging will
internally set this flag to false, and additionally set the flag internally set this flag to false, and additionally set the flag
property as read-only. The default value for is 'false'. property as read-only. The default value for the component is
'false'.
The PromiscuousMode component specifies whether the LFB is set to The PromiscuousMode component specifies whether the LFB is set to
work as in a promiscuous mode. The default value for is 'false'. work as in a promiscuous mode. The default value for the component
is 'false'.
The TxFlowControl component defines whether the LFB is performing The TxFlowControl component defines whether the LFB is performing
flow control on sending packets. The default value for is 'false'. flow control on sending packets. The default value is 'false'. Note
Note that the component is defined as "optional". If an FE does not that the component is defined as "optional". If an FE does not
implement the component while a CE try to configure the component to implement the component while a CE try to configure the component to
this FE, an error from FE may be responded to CE with error code this FE, an error from FE may be responded to CE with error code
like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or 0x15(E_NOT_SUPPORTED) like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or 0x15(E_NOT_SUPPORTED)
depending on the FE processing. See [RFC5810] for details. depending on the FE processing. See [RFC5810] for details.
The RxFlowControl component defines whether the LFB is performing The RxFlowControl component defines whether the LFB is performing
flow control on receiving packets. The default value for is flow control on receiving packets. The default value is 'false'.The
'false'.The component is also defined as "optional" one. component is also defined as "optional" one.
A struct component, MACInStats, defines a set of statistics for this A struct component, MACInStats, defines a set of statistics for this
LFB, including the number of received packets and the number of LFB, including the number of received packets and the number of
dropped packets. Note that this statistics component is optional to dropped packets. Note that this statistics component is optional to
implementers. If a CE tries to query the componennt while it is not implementers. If a CE tries to query the componennt while it is not
implemented in an FE, an error code will be responded to CE implemented in an FE, an error code will be responded to CE
indicating the error type like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or indicating the error type like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or
0x15(E_NOT_SUPPORTED), depending on the FE implementation. 0x15(E_NOT_SUPPORTED), depending on the FE implementation.
5.1.2.3. Capabilities 5.1.2.3. Capabilities
skipping to change at page 52, line 37 skipping to change at page 52, line 44
The LFB is defined with a singleton output port known as The LFB is defined with a singleton output port known as
"EtherPktsOut". All Output packets are in Ethernet format, possibly "EtherPktsOut". All Output packets are in Ethernet format, possibly
with various Ethernet types, alongside with a metadata indicating the with various Ethernet types, alongside with a metadata indicating the
physical port ID the packet is to go through. This output links to a physical port ID the packet is to go through. This output links to a
downstream LFB that is usually an Ethernet physical LFB like downstream LFB that is usually an Ethernet physical LFB like
EtherPHYcop LFB. EtherPHYcop LFB.
This LFB can optionally participate in Ethernet flow control in This LFB can optionally participate in Ethernet flow control in
cooperation with EtherMACIn LFB. This document does not go into the cooperation with EtherMACIn LFB. This document does not go into the
details of how this is implemented; the reader may refer to some details of how this is implemented. This document also does not
relevant references. This document also does not describe how the describe how the buffers which induce the flow control messages
buffers which induce the flow control messages behave - it is assumed behave - it is assumed that such artifacts exist and describing them
that such artifacts exist and describing them is out of scope in this is out of scope in this document.
document.
Note that as a base definition, functions like multiple virtual MAC Note that as a base definition, functions like multiple virtual MAC
layers are not supported in this LFB version. It may be supported in layers are not supported in this LFB version. It may be supported in
the future by defining a subclass or a new version of this LFB. the future by defining a subclass or a new version of this LFB.
5.1.5.2. Components 5.1.5.2. Components
The AdminStatus component is defined for CE to administratively The AdminStatus component is defined for CE to administratively
manage the status of the LFB. The CE may administratively startup or manage the status of the LFB. The CE may administratively startup or
shutdown the LFB by changing the value of AdminStatus. The default shutdown the LFB by changing the value of AdminStatus. The default
skipping to change at page 53, line 15 skipping to change at page 53, line 22
infers that an EtherMACOut LFB usually coexists with an EtherMACIn infers that an EtherMACOut LFB usually coexists with an EtherMACIn
LFB, both of which share the same administrative status management by LFB, both of which share the same administrative status management by
CE. Alias properties as defined in the ForCES FE model [RFC5812] CE. Alias properties as defined in the ForCES FE model [RFC5812]
will be used by CE to declare the target component this alias refers, will be used by CE to declare the target component this alias refers,
which include the target LFB class and instance IDs as well as the which include the target LFB class and instance IDs as well as the
path to the target component. path to the target component.
The MTU component defines the maximum transmission unit. The MTU component defines the maximum transmission unit.
The optinal TxFlowControl component defines whether the LFB is The optinal TxFlowControl component defines whether the LFB is
performing flow control on sending packets. The default value for is performing flow control on sending packets. The default value is
'false'. Note that this component is defined as an alias of 'false'. Note that this component is defined as an alias of
TxFlowControl component in the EtherMACIn LFB. TxFlowControl component in the EtherMACIn LFB.
The optional RxFlowControl component defines whether the LFB is The optional RxFlowControl component defines whether the LFB is
performing flow control on receiving packets. The default value for performing flow control on receiving packets. The default value is
is 'false'. Note that this component is defined as an alias of 'false'. Note that this component is defined as an alias of
RxFlowControl component in the EtherMACIn LFB. RxFlowControl component in the EtherMACIn LFB.
A struct component, MACOutStats, defines a set of statistics for this A struct component, MACOutStats, defines a set of statistics for this
LFB, including the number of transmitted packets and the number of LFB, including the number of transmitted packets and the number of
dropped packets. This statistics component is optional to dropped packets. This statistics component is optional to
impleneters. impleneters.
5.1.5.3. Capabilities 5.1.5.3. Capabilities
This LFB does not have a list of capabilities. This LFB does not have a list of capabilities.
skipping to change at page 105, line 9 skipping to change at page 105, line 9
As was the case with forwarded IPv4 packets, outgoing ARP packets are As was the case with forwarded IPv4 packets, outgoing ARP packets are
also encapsulated to Ethernet format by the EtherEncap LFB, and then also encapsulated to Ethernet format by the EtherEncap LFB, and then
dispatched to different interfaces via a BasicMetadataDispatch LFB. dispatched to different interfaces via a BasicMetadataDispatch LFB.
The BasicMetadataDispatch LFB dispatches the packets according to the The BasicMetadataDispatch LFB dispatches the packets according to the
L3PortID metadata included in every ARP packet sent from CE. L3PortID metadata included in every ARP packet sent from CE.
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. Ligang Dong and Fenggen Jia were also two of the authors
of earlier documents which this document is evolved from.
Jamal Hadi Salim Jamal Hadi Salim
Mojatatu Networks Mojatatu Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: hadi@mojatatu.com Email: hadi@mojatatu.com
Ligang Dong Ligang Dong
Zhejiang Gongshang University Zhejiang Gongshang University
149 Jiaogong Road 18 Xuezheng Str., Xiasha University Town
Hangzhou 310035 Hangzhou,310018
P.R.China P.R.China
Phone: +86-571-28877751 EMail: donglg@zjsu.edu.cn
EMail: donglg@mail.zjgsu.edu.cn
Fenggen Jia Fenggen Jia
National Digital Switching Center(NDSC) National Digital Switching Center(NDSC)
Jianxue Road Jianxue Road
Zhengzhou 452000 Zhengzhou 452000
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 The authors would like to acknowledge the following people, whose
Dong, Fenggen Jia and Weiming Wang. input has been particularly helpful during development of this
document:
Edward Crabbe
Adrian Farrel
Rong Jin
Bin Zhuge
Ming Gao
Jingjing Zhou
Xiaochun Wu
Derek Atkins
Stephen Farrel
Meral Shirazipour
Jari Arkko
Martin Stiemerling
Stewart Bryant
Richard Barnes
10. IANA Considerations 10. IANA Considerations
IANA has created a registry of ForCES LFB Class Names and the IANA has created a registry of ForCES LFB Class Names and the
corresponding ForCES LFB Class Identifiers, with the location of the corresponding ForCES LFB Class Identifiers, with the location of the
definition of the ForCES LFB Class, in accordance with the rules to definition of the ForCES LFB Class, in accordance with the rules to
use the namespace. use the namespace.
The LFB library in this document needs for unique class names and The LFB library in this document needs for unique class names and
numeric class identifiers of all LFBs. Besides, this document also numeric class identifiers of all LFBs. Besides, this document also
skipping to change at page 109, line 41 skipping to change at page 109, line 41
| 0x0000000C | ValidateErrorID | See Section 4.4 | | 0x0000000C | ValidateErrorID | See Section 4.4 |
| 0x0000000D | L3PortID | See Section 4.4 | | 0x0000000D | L3PortID | See Section 4.4 |
| 0x0000000E | RedirectIndex | See Section 4.4 | | 0x0000000E | RedirectIndex | See Section 4.4 |
| 0x0000000F | MediaEncapInfoIndex | See Section 4.4 | | 0x0000000F | MediaEncapInfoIndex | See Section 4.4 |
+--------------+-------------------------+--------------------------+ +--------------+-------------------------+--------------------------+
Table 2 Table 2
Metadata ID 0x80000000-0xFFFFFFFF Metadata ID 0x80000000-0xFFFFFFFF
Metadata IDs in this range are reserved for vendor private Metadata IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals. extensions and are the responsibility of individuals, i.e., used
according to the Private Use [RFC5226] policy.
10.3. Exception ID 10.3. Exception ID
The Exception ID namespace is 32 bits long. The following is the The Exception ID namespace is 32 bits long. The following is the
guideline for managing the namespace. guideline for managing the namespace.
Exception ID 0x00000000-0x7FFFFFFF Exception ID 0x00000000-0x7FFFFFFF
Exception IDs in this range are Specification Required [RFC5226]. Exception IDs in this range are Specification Required [RFC5226].
An exception ID using this range MUST be documented in an RFC or An exception ID using this range MUST be documented in an RFC or
other permanent and readily available references. other permanent and readily available references.
skipping to change at page 110, line 37 skipping to change at page 110, line 37
| 0x0000000C | HopSelectorInvalid | See Section 4.4 | | 0x0000000C | HopSelectorInvalid | See Section 4.4 |
| 0x0000000D | NextHopLookupFailed | See Section 4.4 | | 0x0000000D | NextHopLookupFailed | See Section 4.4 |
| 0x0000000E | FragRequired | See Section 4.4 | | 0x0000000E | FragRequired | See Section 4.4 |
| 0x0000000F | MetadataNoMatching | See Section 4.4 | | 0x0000000F | MetadataNoMatching | See Section 4.4 |
+--------------+---------------------------------+------------------+ +--------------+---------------------------------+------------------+
Table 3 Table 3
Exception ID 0x80000000-0xFFFFFFFF Exception ID 0x80000000-0xFFFFFFFF
Exception IDs in this range are reserved for vendor private Exception IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals. extensions and are the responsibility of individuals, i.e., used
according to the Private Use [RFC5226] policy.
10.4. Validate Error ID 10.4. Validate Error ID
The Validate Error ID namespace is 32 bits long. The following is The Validate Error ID namespace is 32 bits long. The following is
the guideline for managing the namespace. the guideline for managing the namespace.
Validate Error ID 0x00000000-0x7FFFFFFF Validate Error ID 0x00000000-0x7FFFFFFF
Validate Error IDs in this range are Specification Required Validate Error IDs in this range are Specification Required
[RFC5226]. A Validate Error ID using this range MUST be [RFC5226]. A Validate Error ID using this range MUST be
documented in an RFC or other permanent and readily available documented in an RFC or other permanent and readily available
skipping to change at page 111, line 27 skipping to change at page 111, line 27
| 0x00000007 | InvalidIPv4DstAddr | See Section 4.4 | | 0x00000007 | InvalidIPv4DstAddr | See Section 4.4 |
| 0x00000008 | InvalidIPv6PakcetSize | See Section 4.4 | | 0x00000008 | InvalidIPv6PakcetSize | See Section 4.4 |
| 0x00000009 | NotIPv6Packet | See Section 4.4 | | 0x00000009 | NotIPv6Packet | See Section 4.4 |
| 0x0000000A | InvalidIPv6SrcAddr | See Section 4.4 | | 0x0000000A | InvalidIPv6SrcAddr | See Section 4.4 |
| 0x0000000B | InvalidIPv6DstAddr | See Section 4.4 | | 0x0000000B | InvalidIPv6DstAddr | See Section 4.4 |
+--------------+---------------------------------+------------------+ +--------------+---------------------------------+------------------+
Table 4 Table 4
Validate Error ID 0x80000000-0xFFFFFFFF Validate Error ID 0x80000000-0xFFFFFFFF
Validate Error IDs in this range are reserved for vendor private Validate Error IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals. extensions and are the responsibility of individuals, i.e., used
according to the Private Use [RFC5226] policy.
11. Security Considerations 11. Security Considerations
The ForCES framework document [RFC3746] provides a description of the The ForCES framework document [RFC3746] provides a description of the
security needs for the overall ForCES architecture. For example, the security needs for the overall ForCES architecture. For example, the
ForCES protocol entities must be authenticated per the ForCES ForCES protocol entities must be authenticated per the ForCES
requirements before they can access the information elements requirements before they can access the information elements
described in this document via ForCES. The ForCES protocol document described in this document via ForCES. The ForCES protocol document
[RFC5810] includes a comprehensive set of security mechanisms and [RFC5810] includes a comprehensive set of security mechanisms that
which implementations are required to support, and which deployments implementations are required to support to meet these needs. The
can use to meet these needs. The LFBs defined in this document are SCTP-based Transport Mapping Layer (TML) for the ForCES [RFC5811]
similar to other LFBs modeled by the FE model [RFC5812]. In specifies security mechanisms for transport mapping for ForCES
particular, they have the same security properties. Thus the protocol. The LFBs defined in this document are similar to other
security mechanisms and considerations from the ForCES protocol LFBs modeled by the FE model [RFC5812]. In particular, they have the
document [RFC5810] apply and address the issues. same security properties. Thus the security mechanisms and
considerations from the ForCES protocol document [RFC5810] apply and
address the issues.
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.
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
Layer (TML) for the Forwarding and Control Element
Separation (ForCES) Protocol", RFC 5811, March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model", Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010. RFC 5812, March 2010.
12.2. Informative References 12.2. Informative References
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
skipping to change at page 114, line 13 skipping to change at page 115, line 13
May 2008. May 2008.
Authors' Addresses Authors' Addresses
Weiming Wang Weiming Wang
Zhejiang Gongshang University Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town 18 Xuezheng Str., Xiasha University Town
Hangzhou, 310018 Hangzhou, 310018
P.R.China P.R.China
Phone: +86 571 28877721 Phone: +86 571 28877751
Email: wmwang@zjsu.edu.cn Email: wmwang@zjsu.edu.cn
Evangelos Haleplidis Evangelos Haleplidis
University of Patras University of Patras
Patras, Patras,
Greece Greece
Email: ehalep@ece.upatras.gr Email: ehalep@ece.upatras.gr
Kentaro Ogawa Kentaro Ogawa
 End of changes. 29 change blocks. 
50 lines changed or deleted 86 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/