RFC 6956
Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library
8. IANA Considerations
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. This document registers the unique class names and numeric class identifiers for the LFBs listed in Section 8.1. Besides, this document defines the following namespaces: o Metadata ID, defined in Sections 4.3 and 4.4 o Exception ID, defined in Section 4.4 o Validate Error ID, defined in Section 4.4
8.1. LFB Class Names and LFB Class Identifiers
LFB classes defined by this document belong to LFBs defined by Standards Track RFCs. According to IANA, the registration procedure is Standards Action for the range 0 to 65535 and First Come First Served with any publicly available specification for over 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 6956, | | | | abstracted at physical | Section 5.1.1| | | | layer. | | | | | | | | 4 | EtherMACIn | Define an Ethernet | RFC 6956, | | | | input port at MAC data | Section 5.1.2| | | | link layer. | | | | | | | | 5 |EtherClassifier | Define the process to | RFC 6956, | | | | decapsulate Ethernet | Section 5.1.3| | | | packets and classify | | | | | the packets. | | | | | | | | 6 | EtherEncap | Define the process to | RFC 6956, | | | | encapsulate IP packets | Section 5.1.4| | | | to Ethernet packets. | | | | | | | | 7 | EtherMACOut | Define an Ethernet | RFC 6956 | | | | output port at MAC | Section 5.1.5| | | | data link layer. | | | | | | | | 8 | IPv4Validator | Perform IPv4 packets | RFC 6956, | | | | validation. | Section 5.2.1| | | | | | | 9 | IPv6Validator | Perform IPv6 packets | RFC 6956, | | | | validation. | Section 5.2.2| | | | | | | 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC 6956, | | | | Prefix Match Lookup. | Section 5.3.1| | | | | | | 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC 6956, | | | | Prefix Match Lookup. | Section 5.3.3| | | | | |
| 12 | IPv4NextHop | Define the process of | RFC 6956, | | | | selecting IPv4 next-hop| Section 5.3.2| | | | action. | | | | | | | | 13 | IPv6NextHop | Define the process of | RFC 6956, | | | | selecting IPv6 next-hop| Section 5.3.4| | | | action. | | | | | | | | 14 | RedirectIn | Define the process for | RFC 6956, | | | | CE to inject data | Section 5.4.1| | | | packets into FE LFB | | | | | topology. | | | | | | | | 15 | RedirectOut | Define the process for | RFC 6956, | | | | LFBs in FE to deliver | Section 5.4.2| | | | data packets to CE. | | | | | | | | 16 | BasicMetadata | Dispatch input packets | RFC 6956, | | | Dispatch | to a group output | Section 5.5.1| | | | according to a metadata| | | | | | | | 17 |GenericScheduler| Define a preliminary | RFC 6956, | | | | generic scheduling | Section 5.5.2| | | | process. | | +----------+--------------- +------------------------+--------------+ Table 1
8.2. Metadata ID
The Metadata ID namespace is 32 bits long. Below are the guidelines for managing the namespace. Metadata IDs in the range of 0x00000001-0x7FFFFFFF are Specification Required [RFC5226]. A metadata ID using this range MUST be documented in an RFC or other permanent and readily available reference. Values assigned by this specification: +--------------+-------------------------+--------------------------+ | Value | Name | Definition | +--------------+-------------------------+--------------------------+ | 0x00000000 | Reserved | RFC 6956 | | 0x00000001 | PHYPortID | RFC 6956, Section 4.4 | | 0x00000002 | SrcMAC | RFC 6956, Section 4.4 | | 0x00000003 | DstMAC | RFC 6956, Section 4.4 | | 0x00000004 | LogicalPortID | RFC 6956, Section 4.4 | | 0x00000005 | EtherType | RFC 6956, Section 4.4 | | 0x00000006 | VlanID | RFC 6956, Section 4.4 | | 0x00000007 | VlanPriority | RFC 6956, Section 4.4 | | 0x00000008 | NextHopIPv4Addr | RFC 6956, Section 4.4 | | 0x00000009 | NextHopIPv6Addr | RFC 6956, Section 4.4 | | 0x0000000A | HopSelector | RFC 6956, Section 4.4 | | 0x0000000B | ExceptionID | RFC 6956, Section 4.4 | | 0x0000000C | ValidateErrorID | RFC 6956, Section 4.4 | | 0x0000000D | L3PortID | RFC 6956, Section 4.4 | | 0x0000000E | RedirectIndex | RFC 6956, Section 4.4 | | 0x0000000F | MediaEncapInfoIndex | RFC 6956, Section 4.4 | | 0x80000000- | Reserved for | RFC 6956 | | 0xFFFFFFFF | Private Use | | +--------------+-------------------------+--------------------------+ Table 2
8.3. Exception ID
The Exception ID namespace is 32 bits long. Below are the guidelines for managing the namespace. Exception IDs in the range of 0x00000000-0x7FFFFFFF are Specification Required [RFC5226]. An exception ID using this range MUST be documented in an RFC or other permanent and readily available reference. Values assigned by this specification: +--------------+---------------------------------+------------------+ | Value | Name | Definition | +--------------+---------------------------------+------------------+ | 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 | | 0x00000001 | ClassifyNoMatching | See Section 4.4 | | 0x00000002 | MediaEncapInfoIndexInvalid | See Section 4.4 | | 0x00000003 | EncapTableLookupFailed | See Section 4.4 | | 0x00000004 | BadTTL | See Section 4.4 | | 0x00000005 | IPv4HeaderLengthMismatch | See Section 4.4 | | 0x00000006 | RouterAlertOptions | See Section 4.4 | | 0x00000007 | IPv6HopLimitZero | See Section 4.4 | | 0x00000008 | IPv6NextHeaderHBH | See Section 4.4 | | 0x00000009 | SrcAddressException | See Section 4.4 | | 0x0000000A | DstAddressException | See Section 4.4 | | 0x0000000B | LPMLookupFailed | See Section 4.4 | | 0x0000000C | HopSelectorInvalid | See Section 4.4 | | 0x0000000D | NextHopLookupFailed | See Section 4.4 | | 0x0000000E | FragRequired | See Section 4.4 | | 0x0000000F | MetadataNoMatching | See Section 4.4 | | 0x80000000- | Reserved for | RFC 6956 | | 0xFFFFFFFF | Private Use | | +--------------+---------------------------------+------------------+ Table 3
8.4. Validate Error ID
The Validate Error ID namespace is 32 bits long. Below are the guidelines for managing the namespace. Validate Error IDs in the range of 0x00000000-0x7FFFFFFF are Specification Required [RFC5226]. A Validate Error ID using this range MUST be documented in an RFC or other permanent and readily available reference. 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 | InvalidIPv4LengthFieldSize | See Section 4.4 | | 0x00000005 | InvalidIPv4Checksum | See Section 4.4 | | 0x00000006 | InvalidIPv4SrcAddr | See Section 4.4 | | 0x00000007 | InvalidIPv4DstAddr | See Section 4.4 | | 0x00000008 | InvalidIPv6PacketSize | See Section 4.4 | | 0x00000009 | NotIPv6Packet | See Section 4.4 | | 0x0000000A | InvalidIPv6SrcAddr | See Section 4.4 | | 0x0000000B | InvalidIPv6DstAddr | See Section 4.4 | | 0x80000000- | Reserved for | RFC 6956 | | 0xFFFFFFFF | Private Use | | +--------------+---------------------------------+------------------+ Table 4
9. Security Considerations
The ForCES framework document [RFC3746] provides a description of the security needs for the overall ForCES architecture. For example, the ForCES protocol entities must be authenticated per the ForCES requirements before they can access the information elements described in this document via ForCES. The ForCES protocol document [RFC5810] includes a comprehensive set of security mechanisms that implementations are required to support to meet these needs. SCTP- based Transport Mapping Layer (TML) for the ForCES protocol [RFC5811] specifies security mechanisms for transport mapping for the ForCES protocol. The LFBs defined in this document are similar to other LFBs modeled by the FE model [RFC5812]. In particular, they have the same security properties. Thus, the security mechanisms and considerations from the ForCES protocol document [RFC5810] apply to this document.10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol 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 Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.10.2. Informative References
[IEEE.802-1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Standard 802.1Q, 2011. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
Appendix A. Acknowledgements
The authors would like to acknowledge the following people, whose input was particularly helpful during development of this document: Edward Crabbe Adrian Farrel Rong Jin Bin Zhuge Ming Gao Jingjing Zhou Xiaochun Wu Derek Atkins Stephen Farrell Meral Shirazipour Jari Arkko Martin Stiemerling Stewart Bryant Richard BarnesAppendix B. Contributors
The authors would like to thank Jamal Hadi Salim, Ligang Dong, and Fenggen Jia, all of whom made major contributions to the development of this document. Ligang Dong and Fenggen Jia were also two of the authors of earlier documents from which this document evolved. Jamal Hadi Salim Mojatatu Networks Ottawa, Ontario Canada EMail: hadi@mojatatu.com Ligang Dong Zhejiang Gongshang University 18 Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China EMail: donglg@zjsu.edu.cn Fenggen Jia National Digital Switching Center (NDSC) Jianxue Road Zhengzhou 452000 P.R. China EMail: jfg@mail.ndsc.com.cn
Authors' Addresses
Weiming Wang Zhejiang Gongshang University 18 Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China Phone: +86 571 28877751 EMail: wmwang@zjsu.edu.cn Evangelos Haleplidis University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece EMail: ehalep@ece.upatras.gr Kentaro Ogawa NTT Corporation Tokyo Japan EMail: ogawa.kentaro@lab.ntt.co.jp Chuanhuang Li Hangzhou DPtech 6th Floor, Zhongcai Group, 68 Tonghe Road, Binjiang District Hangzhou 310051 P.R. China EMail: chuanhuang_li@zjsu.edu.cn Joel Halpern Ericsson P.O. Box 6049 Leesburg, VA 20178 USA Phone: +1 703 371 3043 EMail: joel.halpern@ericsson.com