D.Galand O.Marce Internet Draft ALCATEL Document: November 2000 Category: Experimental Active Router Information in Routing Protocols Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This memo documents a way to include information on active routers capabilities in routing protocols. In this document, a special focus will be put on OSPF protocol release 2 [2], meanwhile other routing protocols might be considered. These information on active routers transferred through routing protocols will help active routers to exploit as better as possible the abilities of other active routers. This draft especially focus on OSPF protocol v2 and describes the corresponding opaque LSA complements according to the RFC 2370 [3]. 2. Conventions and terminology used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. Terminology: o Active network Active Router Info. in Routing Protocols November 2000 A network of nodes where nodes are able to process the received data in a specific manner. That means that each active node must be able to run algorithms other than those known at build-time. o Active router An active router is able to execute some code they received or downloaded, taking the IP packets as input data. o Execution environment The environment where the processing of the received data is executed. It gives access of router resources to the executing code. 3. Introduction Active network defines network composed of active nodes where data can be specifically processed. The active routers are able to receive code to be executed with the payload of the IP packets as input. Packets tagged for being processed are called "active packets". The processing takes place into the execution environment (EE) which can be specific to each routers family. For performance purposes, before sending active packets, an active router will appreciate to know the capabilities of other active routers. Then it will use this knowledge to route active packets to the most concerned active routers. 4. Specification 4.1 Active Network information in OSPF As specified in the RFC 2370, opaque LSAs consist of standard LSA header followed by application specific information. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. The information contained in Opaque LSAs may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. This draft can be applied for all type (9, 10 ,11) of opaque LSAs. According to the packet format of the opaque LSA given in appendix A.2 of the RFC 2370, the solution is to use : o The opaque type field of this header in order to define the type specifying that the concerned router is configured with active routers behavior. o The opaque ID field to specify that the Opaque Information is about execution environment of the concerned router. o The Opaque Information field to identify the execution Active Router Info. in Routing Protocols November 2000 environments that the router supports, as well as their characteristics. The format of the Opaque LSA for Active Router capabilities advertising is the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9, 10 or 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EE ID |EE Info Length | EE Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EE Info (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Opaque Type: is the Active Router related Opaque information type registered by IANA. Opaque ID: defines the active router characteristic which is described. The currently reserved value is : 0: Description of Execution Environment EE ID: the unique identifier of the Execution Environment registered by ANANA. EE Info Length: length of extra info related to this Execution Environment, in 32 bits words. The value 0 means that all the info concerning this EE is contained in the remaining 16 bits. EE Info: Info related to this EE, in EE's proprietary format. The EE Info can contain any EE related information, like loaded module, or right access to router characteristics. The detail of this, as well as the format used, are out of the scope of this RFC. 4.2 Active network information for RIPng Active Router Info. in Routing Protocols November 2000 This section is a proposal for a change in the RIPng [5] routing protocol in order to take care of activeness of routers. A RIPng messages contains one or more Route Table Entry (RTE): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IPv6 prefix (16) ~ | | +---------------------------------------------------------------+ | route tag (2) | prefix len (1)| metric (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The metric is a number between 1 and 16 - this last value means infinity, or the value 255 (0xFF) used to specify the immediate next hope. The RIPng with active network capacity defines a specific value to be used into the metric field (proposed value 128 - 0x80 -, to be assigned by IANA) which means that the RTE must be considered as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ EE Info (16) ~ | | +---------------------------------------------------------------+ | EE ID (1) | EE Info # (1) | EE Info L. (1)| 0x80 (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the Active Network Entry (ANE) described hereafter. EE Info: Same as in section 4.1 EE ID: Same as in section 4.1 EE Info #: Number of subsequent RIPng messages which are part of the complete EE Info that this ANE is containing. This field is used to deal with the case where the length of the EE Info to transport is larger than the size which can be transported in one RIPng message, due to the MTU (see section 2.1 in RIPng RFC). If this field has a 0 value, no subsequent message will be sent and the receiving router can decode the EE Info it received in this message (note that even in this case, the complete EE Info data can be spread on multiple ANE in a single message). If the value is different than 0, the receiving router is informed of the number of following RIPng messages which contain a part of this EE Info. Active Router Info. in Routing Protocols November 2000 The EE Info # MUST be the same in all ANE having the same EE ID contained in a given RIPng message. The receiving router MUST check that the number of received messages is correct, and it SHOULD not decode the EE Info until it received all the parts of the message. The emitting router MUST groups all the EE Info part concerning the same EE ID in consecutive messages, that means also that it MUST groups altogether the ANE corresponding to a given EE (i.e. having the same EE ID) in a single RIPng message. EE Info L.: Length of the EE Info used in the ANE, in 8 octets (only the value 1 to 16 should be used). 5. IANA Considerations According to paragraph 7.0 specified in RFC 2370, a special public value will be requested - in the range of 0-127 - for the opaque type related to active routers, when necessary, in conformance with RFC 2434 [6]. 6. Other assignment authority considerations The ID of the Execution Environment should be registered by the Active Network Assignment Number Authority [7]. 7. Security considerations No new security issues are raised by this document. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Moy, J., "OSPF Version 2", RFC 2328, April 1998. 3 Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5 Malkin, G., Minnear, R., RIPng for IPv6, RFC 2080, January 1997. 6 Narten, T., Alvestrand, H., "Guidelines for writing an IANA Considerations sections in RFCs", BCP 26, RFC 2434, October 1998 7 Active Networks Assigned Number Authority, http://www.isi.edu/~braden/anana/ 9. Author's Addresses Damien Galand ALCATEL CRC Route de Nozay, F-91461 Marcoussis Cedex FRANCE Phone: +33 1 69 63 41 84 Email: Damien.Galand@ms.alcatel.fr Olivier Marce ALCATEL CRC Route de Nozay F-91461 Marcoussis Cedex Phone: +33 1 69 63 41 67 Email: Olivier.Marce@ms.alcatel.fr inal draft output. . . . Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Title> Categ7ry -