Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Application Management MIB
RFC 2564

Document	Type	RFC - Proposed Standard (May 1999) Was draft-ietf-applmib-mib (applmib WG)
	Authors	Jon Saperia , Carl W. Kalbfleisch , Randy Presuhn , Cheryl D. Krupczak
	Last updated	2013-03-02
	RFC stream	Internet Engineering Task Force (IETF)
	Formats	txt html pdf htmlized bibtex
	Additional resources	Mailing list discussion
IESG	Responsible AD	(None)
	Send notices to	(None)

Email authors Email WG IPR References Referenced by Search Lists

RFC 2564

IDR Working Group E. Rosen, Ed.
Internet-Draft Juniper Networks, Inc.
Obsoletes: 5512 (if approved) K. Patel
Intended status: Standards Track Arrcus
Expires: January 18, 2018 G. Van de Velde
Nokia
July 17, 2017

The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-07

Abstract

RFC 5512 defines a BGP Path Attribute known as the "Tunnel
Encapsulation Attribute". This attribute allows one to specify a set
of tunnels. For each such tunnel, the attribute can provide the
information needed to create the tunnel and the corresponding
encapsulation header. The attribute can also provide information
that aids in choosing whether a particular packet is to be sent
through a particular tunnel. RFC 5512 states that the attribute is
only carried in BGP UPDATEs that have the "Encapsulation Subsequent
Address Family (Encapsulation SAFI)". This document deprecates the
Encapsulation SAFI (which has never been used in production), and
specifies semantics for the attribute when it is carried in UPDATEs
of certain other SAFIs. This document adds support for additional
tunnel types, and allows a remote tunnel endpoint address to be
specified for each tunnel. This document also provides support for
specifying fields of any inner or outer encapsulations that may be
used by a particular tunnel.

This document obsoletes RFC 5512.

Status of This Memo

quot;This attribute corresponds to the low thirty-two bits of
applPastChannelBytesWritten."
::= { applPastChannelEntry 14 }

applPastChannelLastWriteTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastChannelLastWriteTime attribute reports
the time of the most recent write request made by
this running application element or service instance,
regardless of completion status, for this former
channel.

If no write requests have been made the value of this
attribute shall be '0000000000000000'H "
DEFVAL { '0000000000000000'H }
::= { applPastChannelEntry 15 }

-- ****************************************************************
--
-- applPastFileTable - information specific to former files
--
-- ****************************************************************

Kalbfleisch, et al. Standards Track [Page 55]
RFC 2564 Application Management MIB May 1999

applPastFileTable OBJECT-TYPE
SYNTAX SEQUENCE OF ApplPastFileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The applPastFileTable supplements the
applPastChannelTable for entries corresponding to
channels which were files. The indexing structure is
identical to applPastChannelTable. An entry exists in
the applPastFileTable only if there is a corresponding
(same index values) entry in the applPastChannelTable
and if the channel was a file.

Entries for closed files are removed when the
corresponding entries are removed from the
applPastChannelTable."
::= { applPastChannelGroup 3 }

applPastFileEntry OBJECT-TYPE
SYNTAX ApplPastFileEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An applPastFileEntry provides additional, file-specific
information to complement the corresponding
applPastChannelEntry for a channel which was a file."
INDEX { applElmtOrSvc, applElmtOrSvcId,
applPastChannelIndex }
::= { applPastFileTable 1 }

ApplPastFileEntry ::= SEQUENCE
{
applPastFileName LongUtf8String,
applPastFileSizeHigh Unsigned32,
applPastFileSizeLow Unsigned32,
applPastFileMode INTEGER
}

applPastFileName OBJECT-TYPE
SYNTAX LongUtf8String
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute records the last known value of
applOpenFileName before the channel was closed."
::= { applPastFileEntry 1 }

Kalbfleisch, et al. Standards Track [Page 56]
RFC 2564 Application Management MIB May 1999

applPastFileSizeHigh OBJECT-TYPE
SYNTAX Unsigned32
UNITS "2^32 byte blocks"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute records the value of applOpenFileSizeHigh
at the time this channel was closed.

For example, for a file with a total size of
4,294,967,296 bytes, this attribute would have a value
of 1; for a file with a total size of 4,294,967,295
bytes this attribute's value would be 0."
::= { applPastFileEntry 2 }

applPastFileSizeLow OBJECT-TYPE
SYNTAX Unsigned32
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute records the value of applOpenFileSizeLow
at the time this channel was closed.

For example, for a file with a total size of
4,294,967,296 bytes this attribute would have a value
of 0; for a file with a total size of 4,294,967,295
bytes this attribute's value would be 4,294,967,295."
::= { applPastFileEntry 3 }

applPastFileMode OBJECT-TYPE
SYNTAX INTEGER { read(1),
write(2),
readWrite(3) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute records the value of applOpenFileMode
at the time this channel was closed. "
::= { applPastFileEntry 4 }

-- ****************************************************************
--
-- applPastConTable - information specific to former connections
--
-- ****************************************************************

Kalbfleisch, et al. Standards Track [Page 57]
RFC 2564 Application Management MIB May 1999

applPastConTable OBJECT-TYPE
SYNTAX SEQUENCE OF ApplPastConEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The applPastConTable supplements the applPastChannelTable
for entries corresponding to channels which were
connections. The indexing structure is identical
to applPastChannelTable. An entry exists in the
applPastConTable only if there is a corresponding
(same index values) entry in the applPastChannelTable
and if the channel was a connection.

Entries for closed connections are removed when
the corresponding entries are removed from the
applPastChannelTable."
::= { applPastChannelGroup 4 }

applPastConEntry OBJECT-TYPE
SYNTAX ApplPastConEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An applPastConEntry provides additional,
connection-specific information to complement the
corresponding applPastChannelEntry for a channel which
was a connection."
INDEX { applElmtOrSvc, applElmtOrSvcId,
applPastChannelIndex }
::= { applPastConTable 1 }

ApplPastConEntry ::= SEQUENCE
{
applPastConTransport TDomain,
applPastConNearEndAddr ApplTAddress,
applPastConNearEndpoint SnmpAdminString,
applPastConFarEndAddr ApplTAddress,
applPastConFarEndpoint SnmpAdminString,
applPastConApplication SnmpAdminString
}

applPastConTransport OBJECT-TYPE
SYNTAX TDomain
MAX-ACCESS read-only
STATUS current

Kalbfleisch, et al. Standards Track [Page 58]
RFC 2564 Application Management MIB May 1999

DESCRIPTION
"The applPastConTransport attribute identifies the
transport protocol that was in use for this former
connection. If the transport protocol could not be
determined, the value { 0 0 } shall be used."
DEFVAL { zeroDotZero }
::= { applPastConEntry 1 }

applPastConNearEndAddr OBJECT-TYPE
SYNTAX ApplTAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastConNearEndAddr attribute reports the
transport address and port information for the near
end of this former connection.

If the information could not be determined, the value
shall be a zero-length string."
DEFVAL { "" }
::= { applPastConEntry 2 }

applPastConNearEndpoint OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastConNearEndpoint attribute reports the
fully-qualified domain name and port information for the
near end of this former connection.

The format of this attribute for TCP and UDP-based
protocols is the fully-qualified domain name immediately
followed by a colon which is immediately followed by
the decimal representation of the port number.

If the information could not be determined, the value
shall be a zero-length string."
DEFVAL { "" }
::= { applPastConEntry 3 }

applPastConFarEndAddr OBJECT-TYPE
SYNTAX ApplTAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastConFarEnd attribute reports the transport
address and port information for the far end of this

Kalbfleisch, et al. Standards Track [Page 59]
RFC 2564 Application Management MIB May 1999

former connection.

If not known, as in the case of a connectionless
transport, the value of this attribute shall be a
zero-length string."
DEFVAL { "" }
::= { applPastConEntry 4 }

applPastConFarEndpoint OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastConFarEndpoint attribute reports the
transport address and port information for the far
end of this former connection.

If not known, as in the case of a connectionless
transport, the value of this attribute shall be a
zero-length string."
DEFVAL { "" }
::= { applPastConEntry 5 }

applPastConApplication OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastConApplication attribute identifies the
application layer protocol that was in use. Where
possible, the values defined in [13] shall be used.
If not known, the value of this attribute shall be a
zero-length string."
DEFVAL { "" }
::= { applPastConEntry 6 }

-- ****************************************************************
--
-- applPastTransStreamTable - historical
-- information for transaction stream monitoring
--
-- ****************************************************************

Kalbfleisch, et al. Standards Track [Page 60]
RFC 2564 Application Management MIB May 1999

applPastTransStreamTable OBJECT-TYPE
SYNTAX SEQUENCE OF ApplPastTransStreamEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The applPastTransStreamTable contains common
information for historical transaction statistics."
::= { applPastChannelGroup 5 }

applPastTransStreamEntry OBJECT-TYPE
SYNTAX ApplPastTransStreamEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An applPastTransStreamEntry contains information for
a single former transaction stream. A transaction
stream could have been a network connection, file, or
other source of transactions."
INDEX { applElmtOrSvc, applElmtOrSvcId,
applPastChannelIndex }
::= { applPastTransStreamTable 1 }

ApplPastTransStreamEntry ::= SEQUENCE {
applPastTransStreamDescr SnmpAdminString,
applPastTransStreamUnitOfWork SnmpAdminString,
applPastTransStreamInvokes Unsigned64TC,
applPastTransStreamInvokesLow Unsigned32,
applPastTransStreamInvCumTimes Unsigned32,
applPastTransStreamInvRspTimes Unsigned32,
applPastTransStreamPerforms Unsigned64TC,
applPastTransStreamPerformsLow Unsigned32,
applPastTransStreamPrfCumTimes Unsigned32,
applPastTransStreamPrfRspTimes Unsigned32 }
applPastTransStreamDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransStreamDescr attribute provides a
human-readable description of this transaction stream.

If no descriptive information is available, this
attribute's value shall be a zero-length string."
DEFVAL { "" }
::= { applPastTransStreamEntry 1 }

Kalbfleisch, et al. Standards Track [Page 61]
RFC 2564 Application Management MIB May 1999

applPastTransStreamUnitOfWork OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransStreamUnitOfWork attribute provides a
human-readable definition of what the unit of work is
for this transaction stream.

If no descriptive information is available, this
attribute's value shall be a zero-length string."
DEFVAL { "" }
::= { applPastTransStreamEntry 2 }

applPastTransStreamInvokes OBJECT-TYPE
SYNTAX Unsigned64TC
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Cumulative count of requests / invocations issued
for this transaction stream when it was active."
::= { applPastTransStreamEntry 3 }

applPastTransStreamInvokesLow OBJECT-TYPE
SYNTAX Unsigned32
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object corresponds to the low thirty-two
bits of applPastTransStreamInvokes."
::= { applPastTransStreamEntry 4 }

applPastTransStreamInvCumTimes OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransStreamInvCumTimes attribute reports the
cumulative sum of the lengths of the intervals times
measured between the transmission of requests and the
receipt of (the first of) the corresponding response(s)."
::= { applPastTransStreamEntry 5 }

Kalbfleisch, et al. Standards Track [Page 62]
RFC 2564 Application Management MIB May 1999

applPastTransStreamInvRspTimes OBJECT-TYPE
SYNTAX Unsigned32
UNITS "millisecondsThis 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."

Rosen, et al. Expires January 18, 2018 [Page 1]
Internet-Draft Tunnel Encapsulation Attribute July 2017

This Internet-Draft will expire on January 18, 2018.

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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4
1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4
1.3. Brief Summary of Changes from RFC 5512 . . . . . . . . . 5
1.4. Impact on RFC 5566 . . . . . . . . . . . . . . . . . . . 6
2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 6
3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 8
3.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 8
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 10
3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.6. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 15
3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16
3.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 16
3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 17
3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 17
3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 17
3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 17
3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 17
3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 18
3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 20
4. Extended Communities Related to the Tunnel Encapsulation
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Encapsulation Extended Community . . . . . . . . . . . . 21
4.2. Router's MAC Extended Community . . . . . . . . . . . . . 22
4.3. Color Extended Community . . . . . . . . . . . . . . . . 23

Rosen, et al. Expires January 18, 2018 [Page 2]
Internet-Draft Tunnel Encapsulation Attribute July 2017

5. Semantics and Usage of the Tunnel Encapsulation
attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Routing Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. No Impact on BGP Decision Process . . . . . . . . . . . . 27
6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 27
7. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 28
8. Use of Virtual Network Identifiers and Embedded Labels
when Imposing a Tunnel Encapsulation . . . . . . . . . . . . 29
8.1. Tunnel Types without a Virtual Network Identifier
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Tunnel Types with a Virtual Network Identifier Field . . 29
8.2.1. Unlabeled Address Families . . . . . . . . . . . . . 30
8.2.2. Labeled Address Families . . . . . . . . . . . . . . 30
8.2.2.1. When a Valid VNI has been Signaled . . . . . . . 31
8.2.2.2. When a Valid VNI has not been Signaled . . . . . 31
9. Applicability Restrictions . . . . . . . . . . . . . . . . . 32
10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.1. Subsequent Address Family Identifiers . . . . . . . . . 34
12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 35
12.3. Extended Communities . . . . . . . . . . . . . . . . . . 35
12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 35
12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 36
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 38
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
16.1. Normative References . . . . . . . . . . . . . . . . . . 38
16.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41

1. Introduction

This document obsoletes RFC 5512. The deficiencies of RFC 5512, and
a summary of the changes made, are discussed in Sections 1.1-1.3.
The material from RFC 5512 that is retained has been incorporated
into this document.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when and only when appearing in all capital letters, are
to be interpreted as described in [RFC2119].

Rosen, et al. Expires January 18, 2018 [Page 3]
Internet-Draft Tunnel Encapsulation Attribute July 2017

1.1. Brief Summary of RFC 5512

[RFC5512] defines a BGP Path Attribute known as the Tunnel
Encapsulation attribute. This attribute consists of one or more
TLVs. Each TLV identifies a particular type of tunnel. Each TLV
also contains one or more sub-TLVs. Some of the sub-TLVs, e.g., the
"Encapsulation sub-TLV", contain information that may be used to form
the encapsulation header for the specified tunnel type. Other sub-
TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain
information that aids in determining whether particular packets
should be sent through the tunnel that the TLV identifies.

[RFC5512] only allows the Tunnel Encapsulation attribute to be
attached to BGP UPDATE messages of the Encapsulation Address Family.
These UPDATE messages have an AFI (Address Family Identifier) of 1 or
2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the NLRI
(Network Layer Reachability Information) is an address of the BGP
speaker originating the UPDATE. Consider the following scenario:

o BGP speaker R1 has received and installed UPDATE U;

o UPDATE U's SAFI is the Encapsulation SAFI;

o UPDATE U has the address R2 as its NLRI;

o UPDATE U has a Tunnel Encapsulation attribute.

o R1 has a packet, P, to transmit to destination D;

o R1's best path to D is a BGP route that has R2 as its next hop;

In this scenario, when R1 transmits packet P, it should transmit it
to R2 through one of the tunnels specified in U's Tunnel
Encapsulation attribute. The IP address of the remote endpoint of
each such tunnel is R2. Packet P is known as the tunnel's "payload".

1.2. Deficiencies in RFC 5512

While the ability to specify tunnel information in a BGP UPDATE is
useful, the procedures of [RFC5512] have certain limitations:

o The requirement to use the "
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransStreamInvRspTimes attribute reports the
cumulative sum of the lengths of the intervals measured
between the receipt of the first and last of multiple
responses to a request.

For transaction streams which do not permit multiple
responses to a single request, this attribute will be
zero."
::= { applPastTransStreamEntry 6 }

applPastTransStreamPerforms OBJECT-TYPE
SYNTAX Unsigned64TC
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of transactions performed."
::= { applPastTransStreamEntry 7 }

applPastTransStreamPerformsLow OBJECT-TYPE
SYNTAX Unsigned32
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This objecy reports the low thirty-two bits of
applPastTransStreamPerforms."
::= { applPastTransStreamEntry 8 }

applPastTransStreamPrfCumTimes OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransStreamPrfCumTimes attribute reports the
cumulative sum of the lengths of the intervals measured
between receipt of requests and the transmission of the
corresponding responses."
::= { applPastTransStreamEntry 9 }

Kalbfleisch, et al. Standards Track [Page 63]
RFC 2564 Application Management MIB May 1999

applPastTransStreamPrfRspTimes OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For each transaction performed, the elapsed time between
when the first response is enqueued and when the last
response is enqueued is added to this cumulative sum.

For single-response protocols, the value of
applPastTransStreamPrfRspTimes will be zero."
::= { applPastTransStreamEntry 10 }

-- ****************************************************************
--
-- applPastTransFlowTable
--
-- ****************************************************************

applPastTransFlowTable OBJECT-TYPE
SYNTAX SEQUENCE OF ApplPastTransFlowEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The applPastTransFlowTable contains entries, organized by
application instance or running application element,
direction of flow, and type (request/response) for each
former transaction stream.

The simple model of a transaction used here looks like
this:

Since in some protocols it is possible for an entity
to take on both the invoker and performer roles,
information here is accumulated for transmitted and
received requests, as well as for transmitted and
received responses. Counts are maintained for both
transactions and bytes transferred."
::= { applPastChannelGroup 6 }

Kalbfleisch, et al. Standards Track [Page 64]
RFC 2564 Application Management MIB May 1999

applPastTransFlowEntry OBJECT-TYPE
SYNTAX ApplPastTransFlowEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An applPastTransFlowEntry records transaction throughput
information for requests or response in a particular
direction (transmit / receive) for a transaction stream.

Entries in this table correspond to those in the
applPastTransStreamTable with identical values
for the applElmtOrSvc, applElmtOrSvcId, and the
applPastChannelIndex."
INDEX { applElmtOrSvc,
applElmtOrSvcId,
applPastChannelIndex,
applPastTransFlowDirection,
applPastTransFlowReqRsp }
::= { applPastTransFlowTable 1 }

ApplPastTransFlowEntry ::= SEQUENCE {
applPastTransFlowDirection INTEGER,
applPastTransFlowReqRsp INTEGER,
applPastTransFlowTrans Unsigned64TC,
applPastTransFlowTransLow Unsigned32,
applPastTransFlowBytes Unsigned64TC,
applPastTransFlowBytesLow Unsigned32,
applPastTransFlowTime DateAndTime }

applPastTransFlowDirection OBJECT-TYPE
SYNTAX INTEGER { transmit(1),
receive(2) }
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The applPastTransFlowDirection index serves
to identify an entry as containing information
pertaining to the transmit (1) or receive (2) flow
of a past transaction stream. This index corresponds
to applTransactFlowDirection."
::= { applPastTransFlowEntry 1 }

applPastTransFlowReqRsp OBJECT-TYPE
SYNTAX INTEGER { request(1),
response(2) }
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION

Kalbfleisch, et al. Standards Track [Page 65]
RFC 2564 Application Management MIB May 1999

"The value of the applPastTransFlowReqRsp index indicates
whether this entry contains information on requests
(1), or responses (2). This index corresponds to
applTransactFlowReqRsp."
::= { applPastTransFlowEntry 2 }

applPastTransFlowTrans OBJECT-TYPE
SYNTAX Unsigned64TC
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransFlowTrans attribute reports the number
of request/response (as indicated by the
applPastTransFlowReqRsp index) transactions
received/generated (as indicated by the
applPastTransFlowDirection index) handled on this
transaction stream."
::= { applPastTransFlowEntry 3 }

applPastTransFlowTransLow OBJECT-TYPE
SYNTAX Unsigned32
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute corresponds to the low thirty-two
bits of applPastTransFlowTrans."
::= { applPastTransFlowEntry 4 }

applPastTransFlowBytes OBJECT-TYPE
SYNTAX Unsigned64TC
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransFlowBytes attribute reports the number
of request/response (as indicated by the
applPastTransFlowReqRsp index) bytes received/generated
(as indicated by the applPastTransFlowDirection index)
handled on this transaction stream.

All application layer bytes are included in this count,
including any application layer wrappers, headers, or
other overhead."
::= { applPastTransFlowEntry 5 }

Kalbfleisch, et al. Standards Track [Page 66]
RFC 2564 Application Management MIB May 1999

applPastTransFlowBytesLow OBJECT-TYPE
SYNTAX Unsigned32
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This attribute corresponds to the low thirty-two
bits of applPastTransFlowBytes."
::= { applPastTransFlowEntry 6 }

applPastTransFlowTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransFlowTime attribute records the time of
the processing (receipt or transmission as
indicated by the applPastTransFlowDirection index)
of the last request/response (as indicated by the
applPastTransFlowReqRsp index) on this transaction
stream.

If no requests/responses been received/transmitted by
this entity over this transaction stream, the value
of this attribute shall be '0000000000000000'H "
DEFVAL { '0000000000000000'H }
::= { applPastTransFlowEntry 7 }

-- ****************************************************************
--
-- applPastTransKindTable - transaction statistics broken down
-- according to the kinds of transactions in each direction
-- for a transaction stream.
--
-- ****************************************************************

applPastTransKindTable OBJECT-TYPE
SYNTAX SEQUENCE OF ApplPastTransKindEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The applPastTransKindTable provides transaction
statistics broken down by kinds of transaction.
The definition of the kinds of transactions is
specific to the application protocol in use, and may be
documented in the form of an applicability statement. "
::= { applPastChannelGroup 7 }

Kalbfleisch, et al. Standards Track [Page 67]
RFC 2564 Application Management MIB May 1999

applPastTransKindEntry OBJECT-TYPE
SYNTAX ApplPastTransKindEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An applPastTransKindEntry reports historical data for a
specific service instance or running application
element's use of a specific transaction stream in
a particular direction in requests or responses
(as indicated by the applPastTransFlowReqRsp index)
broken down by transaction kind, as indicated by the
applPastTransKind index."
INDEX { applElmtOrSvc,
applElmtOrSvcId,
applPastChannelIndex,
applPastTransFlowDirection,
applPastTransFlowReqRsp,
applPastTransKind }
::= { applPastTransKindTable 1 }

ApplPastTransKindEntry ::= SEQUENCE
{
applPastTransKind SnmpAdminString,
applPastTransKindTrans Unsigned64TC,
applPastTransKindTransLow Unsigned32,
applPastTransKindBytes Unsigned64TC,
applPastTransKindBytesLow Unsigned32,
applPastTransKindTime DateAndTime
}

applPastTransKind OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1 .. 32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The applPastTransKind index is the human-readable
identifier for a particular transaction kind within
the context of an application protocol. The values
to be used for a particular protocol may be identified
in an applicability statement. This index corresponds
to applTransactKind."
::= { applPastTransKindEntry 1 }

applPastTransKindTrans OBJECT-TYPE
SYNTAX Unsigned64TC
UNITS "transactions"
MAX-ACCESS read-only
STATUS current

Kalbfleisch, et al. Standards Track [Page 68]
"Encapsulation SAFI" presents an
unfortunate operational cost, as each BGP session that may need to
carry tunnel encapsulation information needs to be reconfigured to
support the Encapsulation SAFI. The Encapsulation SAFI has never
been used, and this requirement has served only to discourage the
use of the Tunnel Encapsulation attribute.

Rosen, et al. Expires January 18, 2018 [Page 4]
Internet-Draft Tunnel Encapsulation Attribute July 2017

o There is no way to use the Tunnel Encapsulation attribute to
specify the remote endpoint address of a given tunnel; [RFC5512]
assumes that the remote endpoint of each tunnel is specified as
the NLRI of an UPDATE of the Encapsulation-SAFI.

o If the respective best paths to two different address prefixes
have the same next hop, [RFC5512] does not provide a
straightforward method to associate each prefix with a different
tunnel.

o If a particular tunnel type requires an outer IP or UDP
encapsulation, there is no way to signal the values of any of the
fields of the outer encapsulation.

o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has
one-octet length field. In some cases, a two-octet length field
may be needed.

1.3. Brief Summary of Changes from RFC 5512

In this document we address these deficiencies by:

o Deprecating the Encapsulation SAFI.

o Defining a new "Remote Endpoint Address sub-TLV" that can be
included in any of the TLVs contained in the Tunnel Encapsulation
attribute. This sub-TLV can be used to specify the remote
endpoint address of a particular tunnel.

o Allowing the Tunnel Encapsulation attribute to be carried by BGP
UPDATEs of additional AFI/SAFIs. Appropriate semantics are
provided for this way of using the attribute.

o Defining a number of new sub-TLVs that provide additional
information that is useful when forming the encapsulation header
used to send a packet through a particular tunnel.

o Defining the sub-TLV type field so that a sub-TLV whose type is in
the range from 1 to 127 inclusive has a one-octet length field,
but a sub-TLV whose type is in the range from 128 to 254 inclusive
has a two-octet length field.

One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub-
TLV". For a given tunnel, the encapsulation sub-TLV specifies some
of the information needed to construct the encapsulation header used
when sending packets through that tunnel. This document defines
encapsulation sub-TLVs for a number of tunnel types not discussed in
[RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC7348]),

Rosen, et al. Expires January 18, 2018 [Page 5]
Internet-Draft Tunnel Encapsulation Attribute July 2017

VXLAN-GPE (Generic Protocol Extension for VXLAN, [VXLAN-GPE]), NVGRE
(Network Virtualization Using Generic Routing Encapsulation
[RFC7637]), and MPLS-in-GRE (MPLS in Generic Routing Encapsulation
[RFC2784], [RFC2890], [RFC4023]). MPLS-in-UDP [RFC7510] is also
supported, but an Encapsulation sub-TLV for it is not needed.

Some of the encapsulations mentioned in the previous paragraph need
to be further encapsulated inside UDP and/or IP. [RFC5512] provides
no way to specify that certain information is to appear in these
outer IP and/or UDP encapsulations. This document provides a
framework for including such information in the TLVs of the Tunnel
Encapsulation attribute.

When the Tunnel Encapsulation attribute is attached to a BGP UPDATE
whose AFI/SAFI identifies one of the labeled address families, it is
not always obvious whether the label embedded in the NLRI is to
appear somewhere in the tunnel encapsulation header (and if so,
where), or whether it is to appear in the payload, or whether it can
be omitted altogether. This is especially true if the tunnel
encapsulation header itself contains a "virtual network identifier".
This document provides a mechanism that allows one to signal (by
using sub-TLVs of the Tunnel Encapsulation attribute) how one wants
to use the embedded label when the tunnel encapsulation has its own
virtual network identifier field.

[RFC5512] defines a Tunnel Encapsulation Extended Community, that can
be used instead of the Tunnel Encapsulation attribute under certain
circumstances. This document addresses the issue of how to handle a
BGP UPDATE that carries both a Tunnel Encapsulation attribute and one
or more Tunnel Encapsulation Extended Communities.

1.4. Impact on RFC 5566

[RFC5566] uses the mechanisms defined in [RFC5512]. While this
document obsoletes [RFC5512], it does not address the issue of how to
use the mechanisms of [RFC5566] without also using the Encapsulation
SAFI. Those issues are considered to be outside the scope of this
document.

2. The Tunnel Encapsulation Attribute

The Tunnel Encapsulation attribute is an optional transitive BGP Path
attribute. IANA has assigned the value 23 as the type code of the
attribute. The attribute is composed of a set of Type-Length-Value
(TLV) encodings. Each TLV contains information corresponding to a
particular tunnel type. A TLV is structured as shown in Figure 1:

Rosen, et al. Expires January 18, 2018 [Page 6]
Internet-Draft Tunnel Encapsulation Attribute July 2017

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 Octets) | Length (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Tunnel Encapsulation TLV Value Field

o Tunnel Type (2 octets): identifies a type of tunnel. The field
contains values from the IANA Registry "BGP Tunnel Encapsulation
Attribute Tunnel Types".

Note that for tunnel types whose names are of the form "X-in-Y",
e.g., "MPLS-in-GRE", only packets of the specified payload type
"X" are to be carried through the tunnel of type "Y". This is the
equivalent of specifying a tunnel type "Y" and including in its
TLV a Protocol Type sub-TLV (see Section 3.4.1) specifying
protocol "X". If the tunnel type is "X-in-Y", it is unnecessary,
though harmless, to include a Protocol Type sub-TLV specifying
"X".

o Length (2 octets): the total number of octets of the value field.

o Value (variable): comprised of multiple sub-TLVs.

Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or
2-octet length field (depending on the type), and zero or more octets
of value. A sub-TLV is structured as shown in Figure 2:

+-----------------------------------+
| Sub-TLV Type (1 Octet) |
+-----------------------------------+
| Sub-TLV Length (1 or 2 Octets)|
+-----------------------------------+
| Sub-TLV Value (Variable) |
| |
+-----------------------------------+

Figure 2: Tunnel Encapsulation Sub-TLV Format

o Sub-TLV Type (1 octet): each sub-TLV type defines a certain
property about the tunnel TLV that contains this sub-TLV.

Rosen, et al. Expires January 18, 2018 [Page 7]
Internet-Draft Tunnel Encapsulation Attribute July 2017

o Sub-TLV Length (1 or 2 octets): the total number of octets of the
sub-TLV value field. The Sub-TLV Length field contains 1 octet if
the Sub-TLV Type field contains a value in the range from 1-127.
The Sub-TLV Length field contains two octets if the Sub-TLV Type
field contains a value in the range from 128-254.

o Sub-TLV Value (variable): encodings of the value field depend on
the sub-TLV type as enumerated above. The following sub-sections
define the encoding in detail.

3. Tunnel Encapsulation Attribute Sub-TLVs

In this section, we specify a number of sub-TLVs. These sub-TLVs can
be included in a TLV of the Tunnel Encapsulation attribute.

3.1. The Remote Endpoint Sub-TLV

The Remote Endpoint sub-TLV is a sub-TLV whose value field contains
three sub-fields:

1. a four-octet Autonomous System (AS) number sub-field

2. a two-octet Address Family sub-field

3. an address sub-field, whose length depends upon the Address
Family.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Remote Endpoint Sub-TLV Value Field

The Address Family subfield contains a value from IANA's "Address
Family Numbers" registry. In this document, we assume that the
Address Family is either IPv4 or IPv6; use of other address families
is outside the scope of this document.

If the Address Family subfield contains the value for IPv4, the
address subfield must contain an IPv4 address (a /32 IPv4 prefix).

Rosen, et al. Expires January 18, 2018 [Page 8]
Internet-Draft Tunnel Encapsulation Attribute July 2017

In this case, the length field of Remote Endpoint sub-TLV must
contain the value 10 (0xa).

If the Address Family subfield contains the value for IPv6, the
address sub-field must contain an IPv6 address (a /128 IPv6 prefix).
In this case, the length field of Remote Endpoint sub-TLV must
contain the value 22 (0x16). IPv6 link local addresses are not valid
values of the IP address field.

In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Remote
Endpoint sub-TLV is independent of the address family of the UPDATE
itself. For example, an UPDATE whose NLRI is an IPv4 address may
have a Tunnel Encapsulation attribute containing Remote Endpoint sub-
TLVs that contain IPv6 addresses. Also, different tunnels
represented in the Tunnel Encapsulation attribute may have Remote
Endpoints of different address families.

A two-octet AS number can be carried in the AS number field by
setting the two high order octets to zero, and carrying the number in
the two low order octets of the field.

The AS number in the sub-TLV MUST be the number of the AS to which
the IP address in the sub-TLV belongs.

There is one special case: the Remote Endpoint sub-TLV MAY have a
value field whose Address Family subfield contains 0. This means
that the tunnel's remote endpoint is the UPDATE's BGP next hop. If
the Address Family subfield contains 0, the Address subfield is
omitted, and the Autonomous System number field is set to 0.

If any of the following conditions hold, the Remote Endpoint sub-TLV
is considered to be "malformed":

o The sub-TLV contains the value for IPv4 in its Address Family
subfield, but the length of the sub-TLV's value field is other
than 10 (0xa).

o The sub-TLV contains the value for IPv6 in its Address Family
subfield, but the length of the sub-TLV's value field is other
than 22 (0x16).

o The sub-TLV contains the value zero in its Address Family field,
but the length of the sub-TLV's value field is other than 6, or
the Autonomous System subfield is not set to zero.

o The IP address in the sub-TLV's address subfield is not a valid IP
address (e.g., it's an IPv4 broadcast address).

Rosen, et al. Expires January 18, 2018 [Page 9]
Internet-Draft Tunnel Encapsulation Attribute July 2017

o It can be determined that the IP address in the sub-TLV's address
subfield does not belong to the non-zero AS whose number is in the
its Autonomous System subfield. (See section Section 13 for
discussion of one way to determine this.)

If the Remote Endpoint sub-TLV is malformed, the TLV containing it is
also considered to be malformed, and the entire TLV MUST be ignored.
However, the Tunnel Encapsulation attribute SHOULD NOT be considered
to be malformed in this case; other TLVs in the attribute SHOULD be
processed (if they can be parsed correctly).

When redistributing a route that is carrying a Tunnel Encapsulation
attribute containing a TLV that itself contains a malformed Remote
Endpoint sub-TLV, the TLV SHOULD be removed from the attribute before
redistribution.

See Section 11 for further discussion of how to handle errors that
are encountered when parsing the Tunnel Encapsulation attribute.

If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address that
is valid but not reachable, the sub-TLV is NOT considered to be
malformed, and the containing TLV SHOULD NOT be removed from the
attribute before redistribution. However, the tunnel identified by
the TLV containing that sub-TLV cannot be used until such time as the
address becomes reachable. See Section 5.

3.2. Encapsulation Sub-TLVs for Particular Tunnel Types

This section defines Tunnel Encapsulation sub-TLVs for the following
tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE
([RFC7637]), MPLS-in-GRE ([RFC2784], [RFC2890], [RFC4023]), L2TPv3
([RFC3931]), and GRE ([RFC2784], [RFC2890], [RFC4023]).

Rules for forming the encapsulation based on the information in a
given TLV are given in Sections 5 and 8.

For some tunnel types, the rules are obvious and not mentioned in
this document.

There are also tunnel types for which it is not necessary to define
an Encapsulation sub-TLV, because there are no fields in the
encapsulation header whose values need to be signaled from the remote
endpoint.

Rosen, et al. Expires January 18, 2018 [Page 10]
RFC 2564 Application Management MIB May 1999

DESCRIPTION
"For this transaction stream, this attribute records
the total number of transactions of the type
identified by the indexes. The type is characterized
according to the receive/transmit direction
(applPastTransFlowDirecton), whether it was a request
or a response (applPastTransFlowReqRsp), and the
protocol-specific transaction kind (applPastTransKind).
stream for this transaction kind."
::= { applPastTransKindEntry 2 }

applPastTransKindTransLow OBJECT-TYPE
SYNTAX Unsigned32
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransKindTransLow attribute reports
the low thirty-two bits of applPastTransKindTrans."
::= { applPastTransKindEntry 3 }

applPastTransKindBytes OBJECT-TYPE
SYNTAX Unsigned64TC
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For this transaction stream and transaction kind, the
applPastTransKindBytes attribute reports the number
of bytes received or generated (as indicated by
the applPastTransFlowDirection index) in requests or
responses (as indicated by the applPastTransFlowReqRsp
index).

All application layer bytes are included in this count,
including any application layer wrappers, headers, or
other overhead."
::= { applPastTransKindEntry 4 }

applPastTransKindBytesLow OBJECT-TYPE
SYNTAX Unsigned32
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransKindBytesLow attribute corresponds
to the low thirty-two bits of applPastTransKindBytes."
::= { applPastTransKindEntry 5 }

Kalbfleisch, et al. Standards Track [Page 69]
RFC 2564 Application Management MIB May 1999

applPastTransKindTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applPastTransKindTime attribute records the time of
the processing (receipt or transmission as
indicated by the applPastTransFlowDirection index)
of the last request/response (as indicated by the
applPastTransFlowReqRsp index) of this kind of
transaction on this transaction stream.

If no requests/responses of this kind were
received/transmitted over this transaction stream, the
value of this attribute shall be '0000000000000000'H "
DEFVAL { '0000000000000000'H }
::= { applPastTransKindEntry 6 }

-- ****************************************************************
--
-- applElmtRunControlGroup - monitor and control running
-- application elements
--
-- ****************************************************************

applElmtRunStatusTable OBJECT-TYPE
SYNTAX SEQUENCE OF ApplElmtRunStatusEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides information on running application
elements, complementing information available in the
correspondingly indexed sysApplElmtRunTable [31]."
::= { applElmtRunControlGroup 1 }

applElmtRunStatusEntry OBJECT-TYPE
SYNTAX ApplElmtRunStatusEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An applElmtRunStatusEntry contains information to support
the control and monitoring of a single running application
element."
INDEX { sysApplElmtRunIndex }
::= { applElmtRunStatusTable 1 }

Kalbfleisch, et al. Standards Track [Page 70]
RFC 2564 Application Management MIB May 1999

ApplElmtRunStatusEntry ::= SEQUENCE {
applElmtRunStatusSuspended TruthValue,
applElmtRunStatusHeapUsage Unsigned32,
applElmtRunStatusOpenConnections Unsigned32,
applElmtRunStatusOpenFiles Gauge32,
applElmtRunStatusLastErrorMsg SnmpAdminString,
applElmtRunStatusLastErrorTime DateAndTime }

applElmtRunStatusSuspended OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applElmtRunStatusSuspended attribute reports
whether processing by this running application element
has been suspended, whether by management request or by
other means."
::= { applElmtRunStatusEntry 1 }

applElmtRunStatusHeapUsage OBJECT-TYPE
SYNTAX Unsigned32
UNITS "bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applElmtRunStatusHeapUsage reports the current
approximate heap usage by this running application
element."
::= { applElmtRunStatusEntry 2 }

applElmtRunStatusOpenConnections OBJECT-TYPE
SYNTAX Unsigned32
UNITS "connections"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applElmtRunStatusOpenConnections attribute reports
the current number of open connections in use by this
running application element."
::= { applElmtRunStatusEntry 3 }

applElmtRunStatusOpenFiles OBJECT-TYPE
SYNTAX Gauge32
UNITS "files"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applElmtRunStatusOpenFiles attribute reports the

Kalbfleisch, et al. Standards Track [Page 71]
RFC 2564 Application Management MIB May 1999

current number of open files in use by this running
application element."
::= { applElmtRunStatusEntry 4 }

applElmtRunStatusLastErrorMsg OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applElmtRunStatusLastErrorMessage attribute reports
the most recent error message (typically written to
stderr or a system error logging facility) from this
running application element. If no such message has yet
been generated, the value of this attribute shall be a
zero-length string."
DEFVAL { "" }
::= { applElmtRunStatusEntry 5 }

applElmtRunStatusLastErrorTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The applElmtRunStatusLastErrorTime attribute reports the
time of the most recent error message in
applElmtRunStatusLastErrorMsg.

If no such message has yet been generated, the value
of this attribute shall be '0000000000000000'H "
DEFVAL { '0000000000000000'H }
::= { applElmtRunStatusEntry 6 }

-- ****************************************************************
--
-- applElmtRunControlTable - control running application
-- elements
--
-- ****************************************************************

applElmtRunControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF ApplElmtRunControlEntry
MAX-ACCESS not-accessible
STATUS current

Kalbfleisch, et al. Standards Track [Page 72]
RFC 2564 Application Management MIB May 1999

DESCRIPTION
"This table provides the ability to control application
elements, complementing information available in the
correspondingly indexed sysApplElmtRunTable [31]."
::= { applElmtRunControlGroup 2 }

applElmtRunControlEntry OBJECT-TYPE
SYNTAX ApplElmtRunControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An applElmtRunControlEntry contains information to
support the control of a single running application
element."
INDEX { sysApplElmtRunIndex }
::= { applElmtRunControlTable 1 }

ApplElmtRunControlEntry ::= SEQUENCE {
applElmtRunControlSuspend TruthValue,
applElmtRunControlReconfigure TestAndIncr,
applElmtRunControlTerminate TruthValue }

applElmtRunControlSuspend OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Setting this variable to 'true' requests the suspension
of processing by this running application element.
Setting this variable to 'false' requests that processing
be resumed. The effect, if any, will be reported by the
applElmtRunStatusSuspended attribute."
DEFVAL { false }
::= { applElmtRunControlEntry 1 }

applElmtRunControlReconfigure OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Changing the value of this variable requests that the
running application element re-load its configuration
(like SIGHUP for many UNIX-based daemons).

Note that completion of a SET on this object only implies
that configuration reload was initiated, not necessarily
that the reload has been completed."
::= { applElmtRunControlEntry 2 }

Kalbfleisch, et al. Standards Track [Page 73]
RFC 2564 Application Management MIB May 1999

applElmtRunControlTerminate OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Setting the value of applElmtRunControlTerminate to
'true' requests that the running application element
terminate processing and exit in an orderly manner.
This is a 'polite' shutdown request.

When read, this object's value will be 'false' except
when orderly termination is in progress.

Note that completion of a SET on this object only implies
that termination was initiated, not necessarily that the
termination has been completed."
DEFVAL { false }
::= { applElmtRunControlEntry 3 }

-- ****************************************************************
--
-- Conformance requirements
--
-- ****************************************************************

applicationMibGroups OBJECT IDENTIFIER ::=
{ applicationMibConformance 1}

applicationMonitorGroup OBJECT-GROUP
OBJECTS { applSrvInstQual,
applSrvName,
applSrvIndex,
applSrvInstance,
applOpenChannelOpenTime,
applOpenChannelReadRequestsLow,
applOpenChannelReadFailures,
applOpenChannelBytesReadLow,
applOpenChannelLastReadTime,
applOpenChannelWriteRequestsLow,
applOpenChannelWriteFailures,
applOpenChannelBytesWrittenLow,
applOpenChannelLastWriteTime,
applOpenFileName,
applOpenFileSizeHigh,
applOpenFileSizeLow,
applOpenFileMode,
applOpenConnectionTransport,

Kalbfleisch, et al. Standards Track [Page 74]
RFC 2564 Application Management MIB May 1999

applOpenConnectionNearEndAddr,
applOpenConnectionNearEndpoint,
applOpenConnectionFarEndAddr,
applOpenConnectionFarEndpoint,
applOpenConnectionApplication }
STATUS current
DESCRIPTION
"This group represents the basic capabilities of this MIB."
::= { applicationMibGroups 1 }

applicationFastMonitorGroup OBJECT-GROUP
OBJECTS { applOpenChannelReadRequests,
applOpenChannelBytesRead,
applOpenChannelWriteRequests,
applOpenChannelBytesWritten }
STATUS current
DESCRIPTION
"This group comprises 64-bit counters mandatory in
high-throughput environments, where 32-bit counters
could wrap in less than an hour."
::= { applicationMibGroups 2 }

applicationTransactGroup OBJECT-GROUP
OBJECTS { applTransactStreamDescr,
applTransactStreamUnitOfWork,
applTransactStreamInvokesLow,
applTransactStreamInvCumTimes,
applTransactStreamInvRspTimes,
applTransactStreamPerformsLow,
applTransactStreamPrfCumTimes,
applTransactStreamPrfRspTimes,
applTransactFlowTransLow,
applTransactFlowBytesLow,
applTransactFlowTime,
applTransactKindTransLow,
applTransactKindBytesLow,
applTransactKindTime }
STATUS current
DESCRIPTION
"This group comprises objects appropriate from monitoring
transaction-structured flows."
::= { applicationMibGroups 3 }

applicationFastTransactGroup OBJECT-GROUP
OBJECTS { applTransactStreamInvokes,
applTransactStreamPerforms,
applTransactFlowTrans,
applTransactFlowBytes,

Kalbfleisch, et al. Standards Track [Page 75]
RFC 2564 Application Management MIB May 1999

applTransactKindTrans,
applTransactKindBytes }
STATUS current
DESCRIPTION
"This group comprises 64-bit transaction counters required in
high-throughput environments, where 32-bit counters could
wrap in less than an hour."
::= { applicationMibGroups 4 }

applicationHistoryGroup OBJECT-GROUP
OBJECTS { applPastChannelControlCollect,
applPastChannelControlMaxRows,
applPastChannelControlTimeLimit,
applPastChannelControlRemItems,
applPastChannelOpenTime,
applPastChannelCloseTime,
applPastChannelReadReqsLow,
applPastChannelReadFailures,
applPastChannelBytesReadLow,
applPastChannelLastReadTime,
applPastChannelWriteReqsLow,
applPastChannelWriteFailures,
applPastChannelBytesWritLow,
applPastChannelLastWriteTime,
applPastFileName,
applPastFileSizeHigh,
applPastFileSizeLow,
applPastFileMode,
applPastConTransport,
applPastConNearEndAddr,
applPastConNearEndpoint,
applPastConFarEndAddr,
applPastConFarEndpoint,
applPastConApplication}
STATUS current
DESCRIPTION
"This group models basic historical data."
::= { applicationMibGroups 5 }

applicationFastHistoryGroup OBJECT-GROUP
OBJECTS { applPastChannelReadRequests,
applPastChannelBytesRead,
applPastChannelWriteRequests,
applPastChannelBytesWritten}
STATUS current

Kalbfleisch, et al. Standards Track [Page 76]
RFC 2564 Application Management MIB May 1999

DESCRIPTION
"This group comprises additional 64-bit objects required
for recording historical data in high-volume environments,
where a 32-bit integer would be insufficient."
::= { applicationMibGroups 6 }

applicationTransHistoryGroup OBJECT-GROUP
OBJECTS { applPastTransStreamDescr,
applPastTransStreamUnitOfWork,
applPastTransStreamInvokesLow,
applPastTransStreamInvCumTimes,
applPastTransStreamInvRspTimes,
applPastTransStreamPerformsLow,
applPastTransStreamPrfCumTimes,
applPastTransStreamPrfRspTimes,
applPastTransFlowTransLow,
applPastTransFlowBytesLow,
applPastTransFlowTime,
applPastTransKindTransLow,
applPastTransKindBytesLow,
applPastTransKindTime }
STATUS current
DESCRIPTION
"This group represents historical data for transaction-
structured information streams."
::= { applicationMibGroups 7 }

applicationFastTransHistoryGroup OBJECT-GROUP
OBJECTS { applPastTransFlowTrans,
applPastTransFlowBytes,
applPastTransKindTrans,
applPastTransKindBytes,
applPastTransStreamPerforms,
applPastTransStreamInvokes }
STATUS current
DESCRIPTION
"This group contains 64-bit objects required for historical
records on high-volume transaction-structured streams,
where 32-bit integers would be insufficient."
::= { applicationMibGroups 8 }

applicationRunGroup OBJECT-GROUP
OBJECTS { applElmtRunStatusSuspended,
applElmtRunStatusHeapUsage,
applElmtRunStatusOpenConnections,
applElmtRunStatusOpenFiles,
applElmtRunStatusLastErrorMsg,
applElmtRunStatusLastErrorTime,

Kalbfleisch, et al. Standards Track [Page 77]
RFC 2564 Application Management MIB May 1999

applElmtRunControlSuspend,
applElmtRunControlReconfigure,
applElmtRunControlTerminate }
STATUS current
DESCRIPTION
"This group represents extensions to the system application
MIB."
::= { applicationMibGroups 9 }

applicationMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for the application MIB."
MODULE
MANDATORY-GROUPS { applicationMonitorGroup,
applicationHistoryGroup,
applicationRunGroup }

OBJECT applPastChannelControlCollect
MIN-ACCESS read-only
DESCRIPTION
"This object should be limited to read-only
access in environments with inadequate
security."

OBJECT applPastChannelControlMaxRows
MIN-ACCESS read-only
DESCRIPTION
"This object should be limited to read-only
access in environments with inadequate
security."

OBJECT applPastChannelControlTimeLimit
MIN-ACCESS read-only
DESCRIPTION
"This object should be limited to read-only
access in environments with inadequate
security."

OBJECT applElmtRunControlSuspend
MIN-ACCESS read-only
DESCRIPTION
"This object should be limited to read-only
access in environments with inadequate
security."

Kalbfleisch, et al. Standards Track [Page 78]
RFC 2564 Application Management MIB May 1999

OBJECT applElmtRunControlReconfigure
MIN-ACCESS read-only
DESCRIPTION
"This object should be limited to read-only
access in environments with inadequate
security."

OBJECT applElmtRunControlTerminate
MIN-ACCESS read-only
DESCRIPTION
"This object should be limited to read-only
access in environments with inadequate
security."

GROUP applicationTransactGroup
DESCRIPTION
"The applicationTransactGroup is required when the
information stream processed has a transaction
structure. "

GROUP applicationTransHistoryGroup
DESCRIPTION
"The applicationTransHistoryGroup must be implemented
if applicationTransactGroup and applicationHistoryGroup
are implemented."

GROUP applicationFastMonitorGroup
DESCRIPTION
"The applicationFastMonitorGroup is mandatory when
the applicationMonitorGroup is implemented and its
counts group may exceed what can be represented in 32 bits."

GROUP applicationFastTransactGroup
DESCRIPTION
"The applicationFastTransactGroup is mandatory when
the applicationTransactGroup is implemented and its
counts may exceed what can be represented in 32 bits."

GROUP applicationFastHistoryGroup
DESCRIPTION
"The applicationFastHistoryGroup is mandatory when
the applicationHistoryGroup is implemented and its
counts may exceed what can be represented in 32 bits."

Kalbfleisch, et al. Standards Track [Page 79]
RFC 2564 Application Management MIB May 1999

GROUP applicationFastTransHistoryGroup
DESCRIPTION
"The applicationFastTransHistoryGroup is mandatory when
the applicationTransHistoryGroup is implemented and its
counts may exceed what can be represented in 32 bits."
::= { applicationMibConformance 2 }

END

6. Implementation Issues

Unlike the system application MIB [31], in many environments support
for much of this MIB requires instrumentation built into the managed
resource. Some tables may be implemented by a single monitor
process; for others, the implementation may be distributed within the
managed system with the resources being managed.

As a practical matter, this means that the management infrastructure
of the managed system must support different subagents taking
responsibility for different rows of a single table. This can be
supported by AgentX [25], as well as some other subagent protocols
such as [8], [9], and [11].

The sysApplRunElmtIndex is the key connection between this MIB and
the systems application MIB. Implementations of these two MIBs
intended to run concurrently on a given platform must employ a
consistent policy for assigning this value to running application
elements.

Some of the objects defined in this MIB may carry a high run-time
cost in some environments. For example, tracking transaction elapsed
time could be expensive if it required two kernel calls (start and
finish) per transaction. Similarly, maintaining tables of per-
transaction information, rather than aggregating information by
transaction type or transaction stream, could have significant
storage and performance impacts.

Unless a collision-free mechanism for allocating service instance
indexes is in place, the structure of the service-level tables makes
an index-reservation mechanism necessary. AgentX [25] is an example
of a subagent protocol capable of satisfying this requirement.

7. Intellectual Property

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in

Kalbfleisch, et al. Standards Track [Page 80]
RFC 2564 Application Management MIB May 1999

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.

8. Acknowledgements

This document was produced by the Application MIB working group.

The editor gratefully acknowledges the comments and contributions of
the following individuals:

Harrie Hazewinkel
Carl Kalbfleisch
Cheryl Krupczak
David Partain
Jon Saperia
Juergen Schoenwaelder
Kenneth White

9. Security Considerations

By making potentially sensitive information externally accessible,
the capabilities supported by the MIB have the potential of becoming
security problems. How security fits into SNMP frameworks is
described in [26], and a specific access control model is described
in [30].

The tables in this MIB are organized to separate sensitive control
capabilities from less sensitive usage information. For example, the
objects to control application suspend/resume are separated from
those to handle reconfiguration, which in turn are distinct from
those for termination. This recognizes the need to support
configurations where the level of authorization needed by a manager
to do a "reconfigure" might be substantially less than the level
needed to terminate an application element. By keeping these in

Kalbfleisch, et al. Standards Track [Page 81]
RFC 2564 Application Management MIB May 1999

separate columns, we make it possible to set up access control that
allows, for example, "reconfigure" but not "kill".

The MIB is structured to be useful for managers with read-only access
rights. In some environments, it may be approprate to restrict even
read-only access to these MIBs.

The capabilities supported by this MIB include several that may be of
value to a security administrator. These include the ability to
monitor the level of usage of a given application, and to check the
integrity of application components.

10. References

[1] ARM Working Group, "Application Response Measurement (ARM) API
Guide, Version 2", September, 1997.

[2] IEEE P1387.2, POSIX System Administration - Part 2: Software
Administration. (Draft)

[3] ITU-T Recommendation X.744 | ISO/IEC IS 10164-18:1996,
Information Technology - Open Systems Interconnection - Systems
Management: Software Management Function, 1996.

[4] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.

[5] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.

[6] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.

[7] Rose, M., &Internet-Draft Tunnel Encapsulation Attribute July 2017

3.2.1. VXLAN

This document defines an encapsulation sub-TLV for VXLAN tunnels.
When the tunnel type is VXLAN, the following is the structure of the
value field in the encapsulation sub-TLV:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: VXLAN Encapsulation Sub-TLV

V: This bit is set to 1 to indicate that a "valid" VN-ID (Virtual
Network Identifier) is present in the encapsulation sub-TLV.
Please see Section 8.

M: This bit is set to 1 to indicate that a valid MAC Address is
present in the encapsulation sub-TLV.

R: The remaining bits in the 8-bit flags field are reserved for
further use. They SHOULD always be set to 0.

VN-ID: If the V bit is set, the VN-id field contains a 3 octet VN-
ID value. If the V bit is not set, the VN-id field SHOULD be set
to zero.

MAC Address: If the M bit is set, this field contains a 6 octet
Ethernet MAC address. If the M bit is not set, this field SHOULD
be set to all zeroes.

When forming the VXLAN encapsulation header:

o The values of the V, M, and R bits are NOT copied into the flags
field of the VXLAN header. The flags field of the VXLAN header is
set as per [RFC7348].

o If the M bit is set, the MAC Address is copied into the Inner
Destination MAC Address field of the Inner Ethernet Header (see
section 5 of [RFC7348].

Rosen, et al. Expires January 18, 2018 [Page 11]
Internet-Draft Tunnel Encapsulation Attribute July 2017

If the M bit is not set, and the payload being sent through the
VXLAN tunnel is an ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's ethernet header.

If the M bit is not set, and the payload being sent through the
VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC
address field is set to a configured value; if there is no
configured value, the VXLAN tunnel cannot be used.

o See Section 8 to see how the VNI field of the VXLAN encapsulation
header is set.

Note that in order to send an IP packet or an MPLS packet through a
VXLAN tunnel, the packet must first be encapsulated in an ethernet
header, which becomes the "inner ethernet header" described in
[RFC7348]. The VXLAN Encapsulation sub-TLV may contain information
(e.g.,the MAC address) that is used to form this ethernet header.

3.2.2. VXLAN-GPE

This document defines an encapsulation sub-TLV for VXLAN tunnels.
When the tunnel type is VXLAN-GPE, the following is the structure of
the value field in the encapsulation sub-TLV:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|V|R|R|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VN-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: VXLAN GPE Encapsulation Sub-TLV

V: This bit is set to 1 to indicate that a "valid" VN-ID is
present in the encapsulation sub-TLV. Please see Section 8.

R: The bits designated "R" above are reserved for future use.
They SHOULD always be set to zero.

Version (Ver): Indicates VXLAN GPE protocol version. (See the
"Version Bits" section of [VXLAN-GPE].) If the indicated version
is not supported, the TLV that contains this Encapsulation sub-TLV
MUST be treated as specifying an unsupported tunnel type. The
value of this field will be copied into the corresponding field of
the VXLAN encapsulation header.

Rosen, et al. Expires January 18, 2018 [Page 12]
Internet-Draft Tunnel Encapsulation Attribute July 2017

VN-ID: If the V bit is set, this field contains a 3 octet VN-ID
value. If the V bit is not set, this field SHOULD be set to zero.

When forming the VXLAN-GPE encapsulation header:

o The values of the V and R bits are NOT copied into the flags field
of the VXLAN-GPE header. However, the values of the Ver bits are
copied into the VXLAN-GPE header. Other bits in the flags field
of the VXLAN-GPE header are set as per [VXLAN-GPE].

o See Section 8 to see how the VNI field of the VXLAN-GPE
encapsulation header is set.

3.2.3. NVGRE

This document defines an encapsulation sub-TLV for NVGRE tunnels.
When the tunnel type is NVGRE, the following is the structure of the
value field in the encapsulation sub-TLV:

Figure 6: NVGRE Encapsulation Sub-TLV

V: This bit is set to 1 to indicate that a "valid" VN-ID is
present in the encapsulation sub-TLV. Please see Section 8.

M: This bit is set to 1 to indicate that a valid MAC Address is
present in the encapsulation sub-TLV.

R: The remaining bits in the 8-bit flags field are reserved for
further use. They SHOULD always be set to 0.

VN-ID: If the V bit is set, the VN-id field contains a 3 octet VN-
ID value. If the V bit is not set, the VN-id field SHOULD be set
to zero.

MAC Address: If the M bit is set, this field contains a 6 octet
Ethernet MAC address. If the M bit is not set, this field SHOULD
be set to all zeroes.

Rosen, et al. Expires January 18, 2018 [Page 13]
Internet-Draft Tunnel Encapsulation Attribute July 2017

When forming the NVGRE encapsulation header:

o The values of the V, M, and R bits are NOT copied into the flags
field of the NVGRE header. The flags field of the VXLAN header is
set as per [RFC7637].

o If the M bit is set, the MAC Address is copied into the Inner
Destination MAC Address field of the Inner Ethernet Header (see
section 3.2 of [RFC7637].

If the M bit is not set, and the payload being sent through the
NVGRE tunnel is an ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's ethernet header.

If the M bit is not set, and the payload being sent through the
NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC
address field is set to a configured value; if there is no
configured value, the NVGRE tunnel cannot be used.

o See Section 8 to see how the VSID (Virtual Subnet Identifier)
field of the NVGRE encapsulation header is set.

3.2.4. L2TPv3

When the tunnel type of the TLV is L2TPv3 over IP, the following is
the structure of the value field of the encapsulation sub-TLV:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cookie (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: L2TPv3 Encapsulation Sub-TLV

Session ID: a non-zero 4-octet value locally assigned by the
advertising router that serves as a lookup key in the incoming
packet's context.

Cookie: an optional, variable length (encoded in octets -- 0 to 8
octets) value used by L2TPv3 to check the association of a

Rosen, et al. Expires January 18, 2018 [Page 14]
Internet-Draft Tunnel Encapsulation Attribute July 2017

received data message with the session identified by the Session
ID. Generation and usage of the cookie value is as specified in
[RFC3931].

The length of the cookie is not encoded explicitly, but can be
calculated as (sub-TLV length - 4).

3.2.5. GRE

When the tunnel type of the TLV is GRE, the following is the
structure of the value field of the encapsulation sub-TLV:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: GRE Encapsulation Sub-TLV

GRE Key: 4-octet field [RFC2890] that is generated by the
advertising router. The actual method by which the key is
obtained is beyond the scope of this document. The key is
inserted into the GRE encapsulation header of the payload packets
sent by ingress routers to the advertising router. It is intended
to be used for identifying extra context information about the
received payload.

Note that the key is optional. Unless a key value is being
advertised, the GRE encapsulation sub-TLV MUST NOT be present.

3.2.6. MPLS-in-GRE

When the tunnel type is MPLS-in-GRE, the following is the structure
of the value field in an optional encapsulation sub-TLV:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE-Key (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: MPLS-in-GRE Encapsulation Sub-TLV

GRE-Key: 4-octet field [RFC2890] that is generated by the
advertising router. The actual method by which the key is
obtained is beyond the scope of this document. The key is

Rosen, et al. Expires January 18, 2018 [Page 15]
Internet-Draft Tunnel Encapsulation Attribute July 2017

inserted into the GRE encapsulation header of the payload packets
sent by ingress routers to the advertising router. It is intended
to be used for identifying extra context information about the
received payload. Note that the key is optional. Unless a key
value is being advertised, the MPLS-in-GRE encapsulation sub-TLV
MUST NOT be present.

Note that the GRE tunnel type defined in Section 3.2.5 can be used
instead of the MPLS-in-GRE tunnel type when it is necessary to
encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel
type is equivalent to including a TLV of the GRE tunnel type that
also includes a Protocol Type sub-TLV (Section 3.4.1) specifying MPLS
as the protocol to be encapsulated. That is, if a TLV specifies
MPLS-in-GRE or if it includes a Protocol Type sub-TLV specifying
MPLS, the GRE tunnel advertised in that TLV MUST NOT be used for
carrying IP packets.

While it is not really necessary to have both the GRE and MPLS-in-GRE
tunnel types, both are included for reasons of backwards
compatibility.

3.3. Outer Encapsulation Sub-TLVs

The Encapsulation sub-TLV for a particular tunnel type allows one to
specify the values that are to be placed in certain fields of the
encapsulation header for that tunnel type. However, some tunnel
types require an outer IP encapsulation, and some also require an
outer UDP encapsulation. The Encapsulation sub-TLV for a given
tunnel type does not usually provide a way to specify values for
fields of the outer IP and/or UDP encapsulations. If it is necessary
to specify values for fields of the outer encapsulation, additional
sub-TLVs must be used. This document defines two such sub-TLVs.

If an outer encapsulation sub-TLV occurs in a TLV for a tunnel type
that does not use the corresponding outer encapsulation, the sub-TLV
is treated as if it were an unknown type of sub-TLV.

3.3.1. IPv4 DS Field

Most of the tunnel types that can be specified in the Tunnel
Encapsulation attribute require an outer IP encapsulation. The IPv4
Differentiated Services (DS) Field sub-TLV can be carried in the TLV
of any such tunnel type. It specifies the setting of the one-octet
Differentiated Services field in the outer IP encapsulation (see
[RFC2474]). The value field is always a single octet.

Rosen, et al. Expires January 18, 2018 [Page 16]
Internet-Draft Tunnel Encapsulation Attribute July 2017

3.3.2. UDP Destination Port

Some of the tunnel types that can be specified in the Tunnel
Encapsulation attribute require an outer UDP encapsulation.
Generally there is a standard UDP Destination Port value for a
particular tunnel type. However, sometimes it is useful to be able
to use a non-standard UDP destination port. If a particular tunnel
type requires an outer UDP encapsulation, and it is desired to use a
UDP destination port other than the standard one, the port to be used
can be specified by including a UDP Destination Port sub-TLV. The
value field of this sub-TLV is always a two-octet field, containing
the port value.

3.4. Sub-TLVs for Aiding Tunnel Selection

3.4.1. Protocol Type Sub-TLV

The protocol type sub-TLV MAY be included in a given TLV to indicate
the type of the payload packets that may be encapsulated with the
tunnel parameters that are being signaled in the TLV. The value
field of the sub-TLV contains a 2-octet value from IANA's ethertype
registry [Ethertypes].

For example, if we want to use three L2TPv3 sessions, one carrying
IPv4 packets, one carrying IPv6 packets, and one carrying MPLS
packets, the egress router will include three TLVs of L2TPv3
encapsulation type, each specifying a different Session ID and a
different payload type. The protocol type sub-TLV for these will be
IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and
MPLS (protocol type = 0x8847), respectively. This informs the
ingress routers of the appropriate encapsulation information to use
with each of the given protocol types. Insertion of the specified
Session ID at the ingress routers allows the egress to process the
incoming packets correctly, according to their protocol type.

3.4.2. Color Sub-TLV

The color sub-TLV MAY be encoded as a way to "color" the
corresponding tunnel TLV. The value field of the sub-TLV consists of
a Color Extended Community, as defined in Section 4.3. For the use
of this sub-TLV and Extended Community, please see Section 7.

3.5. Embedded Label Handling Sub-TLV

Certain BGP address families (corresponding to particular AFI/SAFI
pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in
their NLRIs. We will use the term "embedded label" to refer to the

Rosen, et al. Expires January 18, 2018 [Page 17]
Internet-Draft Tunnel Encapsulation Attribute July 2017

MPLS label that is embedded in an NLRI, and the term "labeled address
family" to refer to any AFI/SAFI that has embedded labels.

Some of the tunnel types (e.g., VXLAN, VXLAN-GPE, and NVGRE) that can
be specified in the Tunnel Encapsulation attribute have an
encapsulation header containing "Virtual Network" identifier of some
sort. The Encapsulation sub-TLVs for these tunnel types may
optionally specify a value for the virtual network identifier.

Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of
an embedded address family, and it is decided to use a particular
tunnel (specified in one of the attribute's TLVs) for transmitting a
packet that is being forwarded according to that UPDATE. When
forming the encapsulation header for that packet, different
deployment scenarios require different handling of the embedded label
and/or the virtual network identifier. The Embedded Label Handling
sub-TLV can be used to control the placement of the embedded label
and/or the virtual network identifier in the encapsulation.

The Embedded Label Handling sub-TLV may be included in any TLV of the
Tunnel Encapsulation attribute. If the Tunnel Encapsulation
attribute is attached to an UPDATE of a non-labeled address family,
the sub-TLV is treated as a no-op. If the sub-TLV is contained in a
TLV whose tunnel type does not have a virtual network identifier in
its encapsulation header, the sub-TLV is treated as a no-op. In
those cases where the sub-TLV is treated as a no-op, it SHOULD NOT be
stripped from the TLV before the UPDATE is forwarded.

The sub-TLV's Length field always contains the value 1, and its value
field consists of a single octet. The following values are defined:

1: The payload will be an MPLS packet with the embedded label at the
top of its label stack.

2: The embedded label is not carried in the payload, but is carried
either in the virtual network identifier field of the
encapsulation header, or else is ignored entirely.

Please see Section 8 for the details of how this sub-TLV is used when
it is carried by an UPDATE of a labeled address family.

3.6. MPLS Label Stack Sub-TLV

This sub-TLV allows an MPLS label stack ([RFC3032]) to be associated
with a particular tunnel.

The value field of this sub-TLV is a sequence of MPLS label stack
entries. The first entry in the sequence is the "topmost" label, the

Rosen, et al. Expires January 18, 2018 [Page 18]
Internet-Draft Tunnel Encapsulation Attribute July 2017

final entry in the sequence is the "bottommost" label. When this
label stack is pushed onto a packet, this ordering MUST be preserved.

Each label stack entry has the following format:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: MPLS Label Stack Sub-TLV

If a packet is to be sent through the tunnel identified in a
particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV,
then the label stack appearing in the sub-TLV MUST be pushed onto the
packet. This label stack MUST be pushed onto the packet before any
other labels are pushed onto the packet.

In particular, if the Tunnel Encapsulation attribute is attached to a
BGP UPDATE of a labeled address family, the contents of the MPLS
Label Stack sub-TLV MUST be pushed onto the packet before the label
embedded in the NLRI is pushed onto the packet.

If the MPLS label stack sub-TLV is included in a TLV identifying a
tunnel type that uses virtual network identifiers (see Section 8),
the contents of the MPLS label stack sub-TLV MUST be pushed onto the
packet before the procdures of Section 8 are applied.

The number of label stack entries in the sub-TLV MUST be determined
from the sub-TLV length field. Thus it is not necessary to set the S
bit in any of the label stack entries of the sub-TLV, and the setting
of the S bit is ignored when parsing the sub-TLV. When the label
stack entries are pushed onto a packet that already has a label
stack, the S bits of all the entries MUST be cleared. When the label
stack entries are pushed onto a packet that does not already have a
label stack, the S bit of the bottommost label stack entry MUST be
set, and the S bit of all the other label stack entries MUST be
cleared..

By default, the TC (Traffic Class) field ([RFC3032], [RFC5462]) of
each label stack entry is set to 0. This may of course be changed by
policy at the originator of the sub-TLV. When pushing the label
stack onto a packet, the TC of the label stack entries is preserved
by default. However, local policy at the router that is pushing on
the stack MAY cause modification of the TC values.

Rosen, et al. Expires January 18, 2018 [Page 19]
Internet-Draft Tunnel Encapsulation Attribute July 2017

By default, the TTL (Time to Live) field of each label stack entry is
set to 255. This may be changed by policy at the originator of the
sub-TLV. When pushing the label stack onto a packet, the TTL of the
label stack entries is preserved by default. However, local policy
at the router that is pushing on the stack MAY cause modification of
the TTL values. If any label stack entry in the sub-TLV has a TTL
value of zero, the router that is pushing the stack on a packet MUST
change the value to a non-zero value.

Note that this sub-TLV can be appear within a TLV identifying any
type of tunnel, not just within a TLV identifying an MPLS tunnel.
However, if this sub-TLV appears within a TLV identifying an MPLS
tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role
that would be played by an MPLS Encapsulation sub-TLV. Therefore, an
MPLS Encapsulation sub-TLV is not defined.

3.7. Prefix-SID Sub-TLV

[Prefix-SID-Attribute] defines a BGP Path attribute known as the
"Prefix-SID Attribute". This attribute is defined to contain a
sequence of one or more TLVs, where each TLV is either a "Label-
Index" TLV, an "IPv6 SID (Segment Identifier)" TLV, or an "Originator
SRGB (Source Routing Global Block)" TLV.

In this document, we define a Prefix-SID sub-TLV. The value field of
the Prefix-SID sub-TLV can be set to any valid value of the value
field of a BGP Prefix-SID attribute, as defined in
[Prefix-SID-Attribute].

The Prefix-SID sub-TLV can occur in a TLV identifying any type of
tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB
MUST be interpreted to be the SRGB used by the tunnel's Remote
Endpoint. The Label-Index, if present, is the Segment Routing SID
that the tunnel"A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.

[8] Rose, M., "SNMP MUX Protocol and MIB", RFC 1227, May 1991.

[9] Carpenter, G. and B. Wijnen, "SNMP-DPI Simple Network Management
Protocol Distributed Program Interface", RFC 1228, May 1991.

[10] Grillo, P. and S. Waldbusser, "Host Resources MIB", RFC 1514,
September 1993.

[11] Carpenter, G., Curran, K., Sehgal, A., Waters, G. and B.
Wijnen, "Simple Network Management Protocol Distributed Protocol
Interface Version 2.0", RFC 1592, March 1994.

Kalbfleisch, et al. Standards Track [Page 82]
RFC 2564 Application Management MIB May 1999

[12] Brower, D., Purvy, R., Daniel, A., Sinykin, M. and J. Smith,
"Relational Database Management System (RDBMS) Management
Information Base (MIB) using SMIv2", RFC 1697, August 1994.

[13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.

[14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.

[15] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.

[16] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.

[17] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.

[18] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996.

[19] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.

[20] McCloghrie, K. and A. Bierman, "Entity MIB using SMIv2", RFC
2037, October 1996.

[21] Kalbfleisch, C., "Applicability of Standards Track MIBs to
Management of World Wide Web Servers", RFC 2039, November 1996.

[22] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[23] Freed, N. and S. Kille, "Network Services Monitoring MIB", RFC
2248, January 1998.

[24] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 2249, January
1998.

[25] Daniele, M., Francisco, D. and B. Wijnen, "Agent Extensibility
(AgentX) Protocol", RFC 2257, January, 1998.

[26] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for

Kalbfleisch, et al. Standards Track [Page 83]
RFC 2564 Application Management MIB May 1999

describing SNMP Management Frameworks", RFC 2571, May 1999.

[27] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, May 1999.

[28] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC
2573, May 1999.

[29] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, May 1999.

[30] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model for the Simple Network Management Protocol
(SNMP)", RFC 2575, May 1999.

[31] Krupczak, C. and J. Saperia, "Definitions of System-Level
Managed Objects for Applications", RFC 2287, February 1998.

11. Authors' Addresses

Carl Kalbfleisch
Verio, Inc.
1950 Stemmons Freeway
2004 INFOMART
Dallas, TX 75207
USA

Phone: +1 972-238-8303
Fax: +1 972-238-0268
EMail: cwk@verio.net

Cheryl Krupczak
Empire Technologies, Inc.
541 Tenth Street, NW Suite 169
Atlanta, GA 30318
USA

Phone: +1 770-384-0184
EMail: cheryl@empiretech.com

Kalbfleisch, et al. Standards Track [Page 84]
RFC 2564 Application Management MIB May 1999

Randy Presuhn (Editor)
BMC Software, Inc.
965 Stewart Drive
Sunnyvale, CA 94086
USA

Phone: +1 408-616-3100
Fax: +1 408-616-3101
EMail: randy_presuhn@bmc.com

Jon Saperia
IronBridge Networks
55 Hayden Avenue
Lexington, MA 02173
USA

Phone: +1 781-402-8029
Fax: +1 781-402-8090
EMail: saperia@mediaone.net

Kalbfleisch, et al. Standards Track [Page 85]
RFC 2564 Application Management MIB May 1999

12. Full Copyright Statement

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 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 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
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Kalbfleisch, et al. Standards Track [Page 86]

Application Management MIB RFC 2564

Application Management MIB
RFC 2564