Internet DRAFT - draft-galand-an-routing
draft-galand-an-routing
D.Galand
O.Marce
Internet Draft ALCATEL
Document: <draft-galand-an-routing-00.txt> 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> <month> <year>
<Lastname>Categ7ry -
