Internet DRAFT - draft-dec-ospf-tags
draft-dec-ospf-tags
Network Working Group W. Dec
Request for Comments: P. Psenak
Category: S. Sturgess
Expiration Date: December 2004 Cisco Systems
File Name: draft-dec-ospf-tags-01.txt June 2004
A Proposal for a Tag Value field in OSPF
draft-dec-ospf-tags-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "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.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document proposes a method for encoding in Open Shortest Path
First (OSPF) Internal and External Link State Advertisements (LSA) a
Tag Value field containing user tag information associated with each
link or prefix described within an LSA.
Dec, Psenak, Sturgess [Page 1]
INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004
1. Introduction
Currently OSPF, as defined in [rfc2328], within LSA Type-1 to LSA
Type-4 does not have a mechanism for assigning user tags to
individual link or prefixes described in these internal LSAs. OSPF
LSA Type-5 and Type-7 allow such a mechanism for external prefixes
and this proposal does not alter it, however it does propose a
uniform format for both internal and external prefix user tags.
The proposal defines in a backward compatible manner, avoiding
replication of link information or definition of new LSA Types, a
method of inserting user tag information into OSPF LSA Types 1-5 via
a Tag Value field. The purpose of the Tag Value field is to allow
user tags to be assigned to links or prefixes described within a
given LSA.
The method of inserting into LSAs the proposed field is dependent
upon the LSA Type and is described within this draft.
2. The OSPF Tag Value Field
Tag Value Field will be used to propagate additional per link or
prefix related user tag information carried in LSAs and is defined as
a 24 bit value. The encoding of the Tag Value MUST follow the
structure defined in Section X.X.
The Tag Value is an attribute of a single link or prefix described
within the LSA entry, just as a metric is an attribute of a link. A
Tag Value applies to one and only one link. If any other links within
an LSA are meant to have the same tag, then the LSA entry for those
links MUST have a separate Tag Value field inserted.
An OSPF Router generating an LSA will typically only insert the Tag
Value attribute for links where such a value is specified in the
configuration or system settings. The insertion of the Tag Value
should be omitted in LSA entries for links for which the Tag Value is
not specified.
For internal LSAs (Type 1 and 3) the Tag Value is inserted into the
corresponding link`s as TOS 129 metric. If a per TOS Tag Value Field
is required, then the TOS 129 metric Tag Value Field, MUST
immediately follow the corresponding TOS' metric field. All Tag Value
Fields in Type-1 LSAs, must be counted in the '# TOS' field
associated with the link as per Section A.4.2 of
[rfc2328]. The TOS 129 metric was chosen because it cannot be used
to represent
any TOS metric due to the ambiguity arising out of the external LSA
Dec, Psenak, Sturgess [Page 2]
INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004
encoding.
The TOS field is not proposed for carrying tags in external (Type 5
and 7) LSAs. Instead the scheme already defined in rfc2328 is used
and a new proposal for encoding the tag, to allow a 24-bit Tag Value
Field, is put forward. This is detailed in Section X.X. Additionally,
Section X.X specifies a way to achieve a per TOS Tag Value field in
external LSAs if required.
2.1. Tag Value Encoding
The 24-bit Tag Value field is structured as shown and explained
below.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsrv | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rsrv
Reserved field for future definition and SHOULD be set to 0x00. No
significance should currently be derived from this field.
Tag
A field that carries a 16-bit administratively user or system
assigned tag for the corresponding link/prefix.
The above fields, unless addressed by name, are referred to as "tag
fields" in the remainder of this document. The term Tag Value will be
used to represent the combined 24-bit field.
2.2. The Tag Value in Router-LSAs (LSA Type 1)
In order to encode the Tag Value information in the Router-LSA
[rfc2328] the 16-bit TOS metric field together with the preceding
unused 8 bit all-0 space is used. This achieves the 24-bit space
required.
Additional per-TOS Tag Value fields MUST immediately follow the
corresponding TOS entry and be inserted as the TOS 129 metric.
Given the above, a OSPF Router-LSA (Type 1) carrying the Tag Value
field appears as:
Dec, Psenak, Sturgess [Page 3]
INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004
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 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 129 | Rsrv | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
2.3. Tag Value Field in Network LSAs (LSA Type 2)
Network LSAs (Type 2) [rfc2328] have no capability to carry the Tag
Value field. However, since the Network LSA is used to derive the
active tree topology for multi-access network segments, in order to
have the ability to assign user tags to such segments the following
method is used: A Designated Router (DR) originating a Network LSA
(Type 2) MUST insert the Tag Value for the multi-access network into
the Router-LSA (Type 1) description of the link it uses to connect to
the DR itself.
Dec, Psenak, Sturgess [Page 4]
INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004
2.4. The Tag Value in Summary-LSAs (LSA Types 3 and 4)
The OSPF Summary-LSA (Type 3 and 4) [rfc2328] defines a 24-bit TOS
Metric. The overall format of a LSA Type 3 or 4 is the same, hence a
Summary-LSA (Type 3 or 4) carrying the Tag Value field appears 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 3 or 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 129 | Rsrv | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
2.5. The Tag Value in External and NSSA External-LSAs (Type 5 and 7)
The encoding of the Tag Value field in OSPF External-LSA (Type 5 and
7) [rfc 2328 and 1587] uses the existing External Route Tag field.
However, since the external tag is defined as a 32 bit field, the 24
bit Tag Value MUST be mapped by pre-pending a value of 0b01111111 to
it. This allows a method for recognizing classical 32 bit tags as
containing the mapped Tag Value field.
Implementations supporting TOS routing should allow independent
setting of the Tag Value field per TOS instance, and appropriate
insertion into the LSA in the respective TOS` External Route Tag.
Thus, External LSAs (Type 5 or 7) carrying the Tag Value field appear
as:
Dec, Psenak, Sturgess [Page 5]
INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004
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 | 5 or 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|1|1|1|1|1|1| Rsrv | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|1|1|1|1|1|1| Rsrv | Tag Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
3. Operation
The LSA propagation rules and path selection as defined in [rfc2328]
remain unchanged by this proposal. The user or system triggered
creation or modification of a Tag Value field for a specific link
MUST trigger the re-flooding of the LSA in the same manner as a
change of a link metric does.
An implementation SHOULD allow the user configuration option of
enabling or disabling the copying or modification of any of the
individual tag fields at OSPF Area Border Routers (ABRs) when
generating a Summary-LSA from Router-LSAs carrying Tag Values. By
default the implementation should not copy any Tag Values into
Summary-LSA or translated External-LSAs
Dec, Psenak, Sturgess [Page 6]
INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004
4. Interoperability
The use TOS value 129 does not present a conflict or interoperability
issue with any well know TOS value (see Appendix A for a list of
defined TOS values).
Deployed systems not aware of the Tag Value field will in the case of
an internal LSA see the Tag Value field as a TOS 129 metric, whilst
in the external LSA case simply as a classical tag.
5. Deployment Considerations
The proposed method of pre-pending the 24-bit Tag Value with the 0 to
the 0b01111111 value when mapping it to the 32-bit External Route Tag
field is compatible with the "Manually Configured Tags" scheme
defined in the historic [rfc1403]. In network deployments where
administratively defined tag values with their first 8-bits being
0b01111111 are already being used, network administrators are advised
to modify such tagging schemes before deploying the described Tag
Value enhancements.
6. IANA Considerations
The internal LSA OSPF TOS(id) 129 will need to be assigned as a well
known value where the TOS metric carries the defined Tag Value field.
The process should aim at gathering consensus from the OSPF
community, or designated experts, on the allocation of this
unassigned TOS value. The assignment of a value other than 129 but
preferably greater than 128 is also acceptable.
Through the Rsvd field, the draft is open for further IANA
assignments which could, but do not have to, designate other formats
of the User Tags.
Dec, Psenak, Sturgess [Page 7]
INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004
7. Security Considerations
The technique described in this document does not introduce any new
security issues into the OSPF protocol. Routing policies or
applications that use information carried in the tags are not
directly associated to the OSPF protocol or this proposal and hence
outside of the scope.
8. Acknowledgements
The authors would like to thank John Evans, Sina Mirtorabi, Russ
White, Alvaro Retana, and Roy Brooks.
9. Normative References
[RFC2328]
J. Moy. OSPF version 2. Technical Report RFC 2328, Internet
Engineering Task Force, 1998.
10. Informative References
[RFC2178]
J. Moy. OSPF version 2. Technical Report RFC 2328, Internet
Engineering Task Force, 1998.
[RFC1583]
J. Moy. OSPF version 2. Technical Report RFC 1583, Internet
Engineering Task Force, 1994.
[RFC2434]
T. Narten, H. Alvestrand. Guidelines for Writing an IANA Considera-
tions Section in RFCs. Internet Engineering Task Force, 1998.
[RFC1403]
K. Varadhan. BGP OSPF Interaction. Technical Report RFC 1403,
Internet Engineering Task Force, 1993.
Dec, Psenak, Sturgess [Page 8]
INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004
11. Authors' Addresses
Wojciech Dec
Cisco Systems, Inc.
Haarlerbergweg 13-19,
Amsterdam 1101 CH, The Netherlands.
E-mail: wdec@cisco.com
Peter Psenak
Cisco Systems, Inc.
De Kleetlaan 6a,
Brussels 1831, Belgium.
E-mail: ppsenak@cisco.com
Scott Sturgess
Cisco Systems, Inc.
De Kleetlaan 6a,
Brussels 1831, Belgium.
E-mail: scsturge@cisco.com
12. IPR Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per-
tain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might
or might not be available; neither does it represent that it has made
any effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights
by implementors or users of this specification can be obtained from
the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Dec, Psenak, Sturgess [Page 9]
INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004
13. Full Copyright Notice
Copyright (C) The Internet Society (2004). 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 implementation 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 derivativeworks. However, this docu-
ment 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 develop-
ing 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 languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Appendix A
Currently the following TOS codes are defined/reserved [rfc2328] for
backward compatibility
OSPF encoding RFC 1349 TOS values
___________________________________________
0 0000 normal service
2 0001 minimize monetary cost
4 0010 maximize reliability
6 0011
8 0100 maximize throughput
10 0101
12 0110
14 0111
16 1000 minimize delay
18 1001
20 1010
22 1011
24 1100
Dec, Psenak, Sturgess [Page 10]
INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004
26 1101
28 1110
30 1111
Dec, Psenak, Sturgess [Page 11]
