Network Working Group U. Chunduri
Internet-Draft Ericsson Inc.
Intended status: Standards Track X. Xu
Expires: January 3, 2016 Huawei
L. Contreras
Telefonica I+D
M. Boucadair
France Telecom
L. Jalil
Verizon
July 2, 2015
Using Operator-defined TLVs for Agile Service Deployment
draft-chunduri-ospf-operator-defined-tlvs-01
Abstract
This document proposes a TLV within the body of the OSPF Router
Information (RI) Opaque LSA, called Operator-defined Sub-TLV
Container TLV. Here the term OSPF means both OSPFv2 and OSPFv3.This
attribute is meant to accommodate policy-based and deployment-
specific use cases.
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 January 3, 2016.
Copyright Notice
Copyright (c) 2015 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
Chunduri, et al. Expires January 3, 2016 [Page 1]
Internet-Draft Operator-defined Sub-TLVs July 2015
(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
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 . . . . . . . . . . . . . . . . . . 3
2. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Operator-defined Sub-TLV Container TLV . . . . . . . . . . . 4
5. Operator-defined Sub-TLV . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
There are some use cases where OSPF is used for service auto-
discovery by using node administrative tags [I-D.ietf-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 Operator-defined Sub-TLV Container TLV. 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. This document gives a framework
where operator information can be transparently injected into the
routing domain.
Chunduri, et al. Expires January 3, 2016 [Page 2]
Internet-Draft Operator-defined Sub-TLVs July 2015
The characterization of the TLV and its associated sub-SLVs is local
to the each administrative domain. Defining new sub-TLVs is
therefore deployment-specific and policy-based. OSPF here denotes
both OSPFv2 and OSPFv3.
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].
2. Sample Use Cases
There can be several possible use cases and applications for
Operator-defined Sub-TLV Container TLV defined in Section 4. This
section provides few examples how operators can deploy services
rapidly by advertising associated attributes. However, the
illustrations listed below are not meant to be restrictive or
exhaustive.
o Advertising Service Functions and it's attributes
Service Function nodes implementing various service functions
within the network need to advertise each service function they
are offering so that a control and/or management entity can
decide which instance to invoke for the delivery of an added-
value service or to react to particular events (such as failure
of a service function instance). Each service can be
identified by a dedicated sub-TLV type while the associated
attributes/identifiers of the service are indicated by the
value part of the corresponding sub-TLV. These identifiers MAY
not be globally unique and MAY not be exposed outside of a
given administrative domain. The Operator-defined sub-TLV
Container TLV could appear multiple times within a given Router
Information (RI) Opaque LSA, when more than one service
function instances needs to be advertised by a given node based
on a local policy.
Advertising service functions and it's attributes also allow a
controller to adjust its policies and react dynamically.
Typical actions would be, to withdraw a service instance from
being invoked in the context of a service delivery, update load
balancing polices, dynamically activate a backup instance, etc.
The mechanisms, on how service information and attributes are
used by an external controller (for example to steer the
traffic) is beyond the scope of this document.
o Dissemination of dynamic information
Chunduri, et al. Expires January 3, 2016 [Page 3]
Internet-Draft Operator-defined Sub-TLVs July 2015
Dissemination of dynamic information that MAY trigger a
decision-making process at a central controller or an external
entity, controlled by the Operator to decide whether, for
example:
* Mobile OSPF routers can use this attribute to leak their
locations using the operator-defined TLV. For example, the
collected information is used by an off-line Traffic
Engineering (TE) engine to tweak OSPF metrics.
* Use the operator-defined TLV to disseminate a planned
maintenance operation date. This can be used to notify a
service node for e.g., a media gateway, CE, etc.
* To put some links in a sleep mode for the sake of power
consumption optimization.
The proposed attribute in this document is operator-defined. As
such, it is the responsibility of the provider to decide which
information can be conveyed as per the pre-defined format specific to
the deployment by means of the operator-defined attributes. It is
out of scope of this document to enumerate an exhaustive list of
deployment use cases.
3. Terminology
This memo makes use of the terms defined in [RFC4970].
4. Operator-defined Sub-TLV Container TLV
A new TLV within the body of the OSPFv2 and OSPFv3 RI Opaque LSA,
called Operator-defined Sub-TLV Container TLV is defined to carry one
or more operator-defined sub-TLVs.
The format of the Operator-defined Sub-TLV Container TLV is shown in
Figure 1.
Chunduri, et al. Expires January 3, 2016 [Page 4]
Internet-Draft Operator-defined Sub-TLVs July 2015
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 Operator-defined Sub-TLV |
o o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Operator-defined Sub-TLV |
o o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Operator-defined Sub-TLV Container TLV
Type: TBD Section 7
Length: A 16-bit field that indicates the length of the value portion
in octets. It MUST be multiple of 4 octets dependent on the number
of Operator-defined Sub-TLVs advertised.
Value: Contains one or more nested TLV triplets of operator-defined
sub-TLVs as defined in Section 5.
There can be more than one TLV of these possible and the flooding
scope of this TLV depends on the application. Being part of the RI
Opaque LSA, the Operator-defined sub-TLV Container TLV inherits
applicability as well as restrictions as specified in Section 3 of
[RFC4970].
5. Operator-defined Sub-TLV
The operator-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 January 3, 2016 [Page 5]
Internet-Draft Operator-defined Sub-TLVs July 2015
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | Attribute Value (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | Attribute Value (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Operator-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 (i.e., within a single administrative domain). The
Value field contains one or more {Attribute-Len, Attribute-value}
tuple. Attribute Length is of 2 bytes, for fixed formatting and
Attribute value as represented by attribute length. All multi byte
attribute values MUST be encoded in Network Byte Order (NBO). If
multiple fixed length values have to be represented, those SHOULD be
represented with multiple {Attribute-Len, Attribute-value} tuples.
The meaning of the operator-defined sub-TLV is totally opaque to OSPF
and is defined by the network local policy and is controlled via
configuration.
Routers advertising the operator-defined sub-TLV are configured to do
so without knowing (or even explicitly supporting) functionality
implied by the sub-TLV.
How a receiving node communicates the operator-defined sub-TLVs with
the policy manager is outside the scope of this document.
There is no need for any specification to define any operator-defined
sub-TLV. Furthermore, the semantics of the operator-defined sub-TLV
order has no meaning. That is, there is no implied meaning to the
ordering of the operator-defined sub-TLV that indicates a certain
operation or set of operations that need to be performed based on the
ordering. The ordering of operator-defined sub-TLVs and the
interpretation of the operator-defined sub-TLV is deployment-
specific. Routers can be configured with local policies if the order
Chunduri, et al. Expires January 3, 2016 [Page 6]
Internet-Draft Operator-defined Sub-TLVs July 2015
of sub-TLV must be preserved. How a router is configured with
additional instructions (such as order preservation) is
implementation-specific.
6. Acknowledgements
Authors would like to thank Acee Lindem for reviewing and providing
suggestions on the initial version of the document. Also thankful to
Anton Smirnov, Peter Psenak, Chris Bowers and Les Ginsberg for their
review and comments.
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].
8. Security Considerations
As Operator Defined TLV specified in this draft is part of RI LSA,
this document does not introduce any new security risk other than
what is specified by [RFC4970]. Security considerations for the base
OSPF protocol are covered in [RFC2328] and [RFC5340].
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.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
9.2. Informative References
[I-D.ietf-ospf-node-admin-tag]
Hegde, S., Raghuveer, H., Gredler, H., Shakir, R.,
Smirnov, A., Li, Z., and B. Decraene, "Advertising per-
node administrative tags in OSPF", draft-ietf-ospf-node-
admin-tag-02 (work in progress), June 2015.
Chunduri, et al. Expires January 3, 2016 [Page 7]
Internet-Draft Operator-defined Sub-TLVs July 2015
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
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/
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Luay Jalil
Verizon
400 International Parkway
Richardson, Tx 75081
USA
Email: luay.jalil@verizon.com
Chunduri, et al. Expires January 3, 2016 [Page 8]