Using Self-defined Sub-TLVs for Agile Service Deployment
draft-chunduri-ospf-self-defined-sub-tlvs-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Uma Chunduri , Xiaohu Xu , Luis M. Contreras | ||
| Last updated | 2014-10-15 | ||
| Replaced by | draft-chunduri-ospf-operator-defined-tlvs | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chunduri-ospf-self-defined-sub-tlvs-00
Network Working Group U. Chunduri
Internet-Draft Ericsson Inc.
Intended status: Standards Track X. Xu
Expires: April 18, 2015 Huawei
L. Contreras
Telefonica I+D
October 15, 2014
Using Self-defined Sub-TLVs for Agile Service Deployment
draft-chunduri-ospf-self-defined-sub-tlvs-00
Abstract
This document proposes a TLV within the body of the OSPF Router
Information (RI) Opaque LSA, called Self-defined Sub-TLV Container
TLV. Here the term OSPF means both OSPFv2 and OSPFv3.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 18, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Chunduri, et al. Expires April 18, 2015 [Page 1]
Internet-Draft Self-defined Sub-TLVs October 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Self-defined Sub-TLV Container TLV . . . . . . . . . . . . . 3
5. Self-defined Sub-TLV . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
There are some use cases where OSPF is used for service auto-
discovery by using node administrative tags [I-D.hegde-ospf-node-
admin-tag] . One major benefit of using administrative tags rather
than IANA defined TLVs or sub-TLVs to indicate different services is
to facilitate the rapid deployment of new services without any need
for the standardization of those TLVs or sub-TLVs. However, there
are some special use cases where the service to be advertised has one
or more attributes which need to be advertised as well. In such
case, the administrative tag is not much applicable anymore.
To inherit the benefit of administrative tags (i.e., allowing
operators to use OSPF for service auto-discovery without the need of
any standardization process) while meeting the requirement of
advertising services and their associated attributes, this document
proposes a TLV within the body of the OSPF Router Information (RI)
Opaque LSA, called Self-defined Sub-TLV Container TLV. Here the term
OSPF means both OSPFv2 and OSPFv3. With such TLV, operators could
flexibly define one or more sub-TLVs indicating one or more services
and their associated attributes without relying on any
standardization process.
1.1. Requirements Language
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 [RFC2119].
Chunduri, et al. Expires April 18, 2015 [Page 2]
Internet-Draft Self-defined Sub-TLVs October 2014
2. Use Cases
There can be several possible use cases and applications for Self-
defined Sub-TLV Container TLV defined in Section 4. But, this
section illustrates few examples how operators can deploy services
rapidly by advertising associated attributes and by no means the
illustrations listed below limit the usage of this TLV.
o Advertising Service functions and it's attributes
Service nodes implementing various services within the network
need to advertise each service function they are offering to a
central entity. Each service type can be identified by an
attribute, which can be a locally unique identifier. The Self-
defined sub-TLV Container TLV could appear multiple times with
in a given Router Information (RI) Opaque LSA, when more than
one service function needs to be advertised by a given node
based on the local policy. The mechanisms, on how this service
information and attributes are used by controller to steer the
traffic is beyond the scope of this document.
o Dissemination of node's dynamic information
It's possible for operators to disseminate the node local
information like energy efficiency, congestion information,
certain critical node statistics periodically to a central
controller managing the network. How a Controller uses this
information is beyond the scope of this document.
3. Terminology
This memo makes use of the terms defined in [RFC4970].
4. Self-defined Sub-TLV Container TLV
A new TLV within the body of the OSPFv2 and OSPFv3 RI Opaque LSA,
called Self-defined Sub-TLV Container TLV is defined to carry one or
more self-defined sub-TLVs.
The format of the Self-defined Sub-TLV Container TLV is as follows:
Chunduri, et al. Expires April 18, 2015 [Page 3]
Internet-Draft Self-defined Sub-TLVs October 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Self-defined Sub-TLV |
o o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |
o
| o |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Self-defined Sub-TLV |
o o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Self-defined Sub-TLV Container TLV
Type: TBD Section 7
Length: A 16-bit field that indicates the length of the value portion
in octets and will be a multiple of 4 octets dependent on the number
of Self-defined Sub-TLVs advertised.
Value: Contains one or more nested TLV triplets of self-defined sub-
TLVs as defined in Section 5.
There can be more than one TLV of these possible in The flooding
scope of this TLV depends on the application. Being part of the RI
Opaque LSA, the Self-defined sub-TLV Container TLV SHOULD be
reasonably small as specified in Section 3 of [RFC4970].
5. Self-defined Sub-TLV
The self-defined sub-TLV has the following structure and can be part
of the Container TLV as defined in Section 4 within the body of the
OSPF RI LSA.
Chunduri, et al. Expires April 18, 2015 [Page 4]
Internet-Draft Self-defined Sub-TLVs October 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... (associated attribute) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Self-defined Sub-TLV
Type: Per Operator/Local Policy.
Length: A 16-bit field that indicates the length of the value portion
in octets and will be padded/formatted as described in Section 2.1 of
[RFC4970].
Value: Represents the associated attribute of the service or Type
defined locally.
The meaning of the self-defined sub-TLV is totally opaque to OSPF.
Routers advertising the self-defined sub-TLV are just configured to
do so without knowing (or even explicitly supporting) functionality
implied by the sub-TLV. Interpretation of the self-defined sub-TLVs
is implementation-specific. The meaning of a self-defined sub-TLV is
defined by the network local policy and is controlled via the
configuration. How a receiving node communicates the self-defined
sub-TLVs with the policy manager is outside the scope of this
document. There is no need for any specification to define any self-
defined sub-TLV. Furthermore, the semantics of the self-defined sub-
TLV order has no meaning. That is, there is no implied meaning to
the ordering of the self-defined sub-TLV that indicates a certain
operation or set of operations that need to be performed based on the
ordering.
6. Acknowledgements
TBD.
7. IANA Considerations
This document includes a request to IANA to allocate a TLV type code
for the new RI LSA TLV proposed in Section 4 of this document from
OSPF Router Information (RI) TLVs Registry defined by [RFC4970].
Chunduri, et al. Expires April 18, 2015 [Page 5]
Internet-Draft Self-defined Sub-TLVs October 2014
8. Security Considerations
This document does not introduce any new security risk other than
what is specified by [RFC4970].
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3", RFC
5838, April 2010.
9.2. Informative References
[I-D.hegde-ospf-node-admin-tag]
Hegde, S., Raghuveer, H., Gredler, H., Shakir, R.,
Smirnov, A., and Z. Li, "Advertising per-node
administrative tags in OSPF", draft-hegde-ospf-node-admin-
tag-02 (work in progress), June 2014.
Authors' Addresses
Uma Chunduri
Ericsson Inc.
300 Holger Way,
San Jose, California 95134
USA
Phone: 408 750-5678
Email: uma.chunduri@ericsson.com
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
Chunduri, et al. Expires April 18, 2015 [Page 6]
Internet-Draft Self-defined Sub-TLVs October 2014
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://people.tid.es/LuisM.Contreras/
Chunduri, et al. Expires April 18, 2015 [Page 7]