PCE communication protocol (PCEP) Management Information Base
draft-ietf-pce-pcep-mib-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7420.
Expired & archived
|
|
|---|---|---|---|
| Authors | Kiran Koushik , Emile Stephan , Quintin Zhao , Daniel King , Jonathan Hardwick | ||
| Last updated | 2013-01-11 (Latest revision 2012-07-10) | ||
| Replaces | draft-kkoushik-pce-pcep-mib | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Telechat review
(of
-10)
by Peter Yee
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7420 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-pce-pcep-mib-03
PCE Working Group A. Koushik
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Emile
Expires: January 11, 2013 France Telecom
Q. Zhao
Huawei Technology
D. King
Old Dog Consulting
J. Hardwick
Metaswitch
July 10, 2012
PCE communication protocol (PCEP) Management Information Base
draft-ietf-pce-pcep-mib-03
Abstract
This memo defines an experimental portion of the Management
Information Base for use with network management protocols in the
Internet community. In particular, it describes managed objects for
modeling of Path Computation Element communication Protocol (PCEP)
for communications between a Path Computation Client (PCC) and a Path
Computation Element (PCE), or between two PCEs.
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 11, 2013.
Copyright Notice
Copyright (c) 2012 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
Koushik, et al. Expires January 11, 2013 [Page 1]
Internet-Draft PCEP MIB July 2012
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
2. The Internet-Standard Management Framework . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. PCEP MIB Module Architecture . . . . . . . . . . . . . . . . . 4
5.1. Relations to other MIB modules . . . . . . . . . . . . . . 4
6. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 4
6.1. PCE-PCEP-DRAFT-MIB . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
9.2. Normative References . . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgement . . . . . . . . . . . . . . . . . . . 26
Koushik, et al. Expires January 11, 2013 [Page 2]
Internet-Draft PCEP MIB July 2012
1. Introduction
The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a
network graph, and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be
computed.
The PCE communication protocol (PCEP) is the communication protocol
between a PCC and PCE for point-to-point (P2P) path computations and
is defined in [RFC5440]. Such PCEP communication interactions
include path computation requests and path computation replies as
well as notifications of specific states related to the use of a PCE
in the context of Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering.
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines a MIB module that can be used to manage
PCEP communications between a PCC and a PCE, or between two PCEs.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
[RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58
[RFC2578] [RFC2579] [RFC2580].
3. 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 BCP 14, RFC 2119
[RFC2119].
4. Terminology
The terminology used in this document is built on notions introduced
and discussed in PCE WG documents. The reader should be familiar
with these documents.
Koushik, et al. Expires January 11, 2013 [Page 3]
7. Framework Operations
In addition to the operation specific object types, all operations
MAY specify the minor version of the protocol that when used in
conjunction with the major version (that can be for instance
specified in the protocol namespace) can serve to identify the
version of the SPPF protocol that the client is using. If the minor
version is not specified, the latest minor version supported by the
SPPF server for the given major version will be used. Additionally,
operations that may potentially modify persistent protocol objects
SHOULD include a transaction ID as well.
7.1. Add Operation
Any conforming transport protocol specification MUST provide a
definition for the operation that adds one or more SPPF objects into
the Registry. If the object, as identified by the request attributes
that form part of the object's key, does not exist, then the Registry
MUST create the object. If the object does exist, then the Registry
MUST replace the current properties of the object with the properties
passed in as part of the Add operation.
If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types"
section of the document.
7.2. Delete Operation
Any conforming transport protocol specification MUST provide a
definition for the operation that deletes one or more SPPF objects
from the Registry using the object's key.
If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types"
section of the document.
When an object is deleted, any references to that object must of
course also be removed as the SPPF server implementation fulfills the
deletion request. Furthermore, the deletion of a composite object
must also result in the deletion of the objects it contains. As a
result, the following rules apply to the deletion of SPPF object
types:
o Destination Groups: When a destination group is deleted any
references between that destination group and any SED group must
be automatically removed by the SPPF implementation as part of
Cartwright, et al. Expires April 25, 2015 [Page 36]
Internet-Draft draft-drinks-spp-framework October 2014
fulfilling the deletion request. Similarly, any references
between that destination group and any Public Identifier must be
removed by the SPPF implementation as part of fulfilling the
deletion request.
o SED Groups: When a SED group is deleted any references between
that SED group and any destination group must be automatically
removed by the SPPF implementation as part of fulfilling the
deletion request. Similarly any references between that SED group
and any SED records must be removed by the SPPF implementation as
part of fulfilling the deletion request. Furthermore, SED group
offers relating that SED group must also be deleted as part of
fulfilling the deletion request.
o SED Records: When a SED record is deleted any references between
that SED record and any SED group must be removed by the SPPF
implementation as part of fulfilling the deletion request.
Similarly, any reference between that SED record and any Public
Identifier must be removed by the SPPF implementation as part of
fulfilling the deletion request.
o Public Identifiers: When a public identifier is deleted any
references between that public identifier and any referenced
destination group must be removed by the SPPF implementation as
part of fulfilling the deletion request. Any references to SED
records associated directly to that Public Identifier must also be
deleted by the SPPF implementation as part of fulfilling the
deletion request.
7.3. Get Operations
At times, on behalf of the Registrant, the Registrar may need to get
information about SPPF objects that were previously provisioned in
the Registry. A few examples include logging, auditing, and pre-
provisioning dependency checking. This query mechanism is limited to
aid provisioning scenarios and should not be confused with query
protocols provided as part of the resolution system (e.g. ENUM and
SIP).
Any conforming "protocol" specification MUST provide a definition for
the operation that queries the details of one or more SPPF objects
from the Registry using the object's key. If the entity that issued
the command is not authorized to perform this operation an
appropriate error message MUST be returned from amongst the response
messages defined in Section 5.3.
Cartwright, et al. Expires April 25, 2015 [Page 37]
Internet-Draft draft-drinks-spp-framework October 2014
If the response to the Get operation includes object(s) that extend
the BasicObjType, the Registry MUST include the 'cDate' and 'mDate',
if applicable.
7.4. Accept Operations
In SPPF, a SED Group Offer can be accepted or rejected by, or on
behalf of, the Registrant to whom the SED Group has been offered
(refer "Framework Data Model Objects" section of this document for a
description of the SED Group Offer object). The Accept operation is
used to accept the SED Group Offers. Any conforming transport
protocol specification MUST provide a definition for the operation to
accept SED Group Offers by, or on behalf of the Registrant, using the
SED Group Offer object key.
Not until access to a SED Group has been offered and accepted will
the Registrant's organization ID be included in the peeringOrg list
in that SED Group object, and that SED Group's peering information
become a candidate for inclusion in the responses to the resolution
requests submitted by that Registrant. A SED Group Offer that is in
the "offered" status is accepted by, or on behalf of, the Registrant
to which it has been offered. When the SED Group Offer is accepted
the the SED Group Offer is moved to the "accepted" status and adds
that data recipient's organization ID into the list of peerOrgIds for
that SED Group.
If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types"
section of the document.
7.5. Reject Operations
In SPPF, a SED Group Offer object can be accepted or rejected by, or
on behalf of, the Registrant to whom the SED Group has been offered
(refer "Framework Data Model Objects" section of this document for a
description of the SED Group Offer object). Furthermore, that offer
may be rejected, regardless of whether or not it has been previously
accepted. The Reject operation is used to reject the SED Group
Offers. When the SED Group Offer is rejected that SED Group Offer is
deleted, and, if appropriate, the data recipient's organization ID is
removed from the list of peeringOrg IDs for that SED Group. Any
conforming transport protocol specification MUST provide a definition
for the operation to reject SED Group Offers by, or on behalf of the
Registrant, using the SED Group Offer object key.
If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from
Cartwright, et al. Expires April 25, 2015 [Page 38]
Internet-Draft draft-drinks-spp-framework October 2014
amongst the response messages defined in "Response Message Types"
section of the document.
7.6. Get Server Details Operation
In SPPF, Get Server Details operation can be used to request certain
details about the SPPF server that include the SPPF server's current
status, the major/minor version of the SPPF protocol supported by the
SPPF server.
Any conforming transport protocol specification MUST provide a
definition for the operation to request such details from the SPPF
server. If the entity that issued the command is not authorized to
perform this operation an appropriate error message MUST be returned
from amongst the response messages defined in "Response Message
Types" section of the document.
8. XML Considerations
XML serves as the encoding format for SPPF, allowing complex
hierarchical data to be expressed in a text format that can be read,
saved, and manipulated with both traditional text tools and tools
specific to XML.
XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the
character case presented to develop a conforming implementation.
This section discusses a small number of XML-related considerations
pertaining to SPPF.
8.1. Namespaces
All SPPF elements are defined in the namespaces in the IANA
Considerations section and in the Formal Framework Specification
section of this document.
8.2. Versioning and Character Encoding
All XML instances SHOULD begin with an <?xml?> declaration to
identify the version of XML that is being used, optionally identify
use of the character encoding used, and optionally provide a hint to
an XML parser that an external schema file is needed to validate the
XML instance.
Conformant XML parsers recognize both UTF-8 (defined in [RFC3629])
and UTF-16 (defined in [RFC2781]); per [RFC2277] UTF-8 is the
RECOMMENDED character encoding for use with SPPF.
Cartwright, et al. Expires April 25, 2015 [Page 39]
Internet-Draft draft-drinks-spp-framework October 2014
Character encodings other than UTF-8 and UTF-16 are allowed by XML.
UTF-8 is the default encoding assumed by XML in the absence of an
"encoding" attribute or a byte order mark (BOM); thus, the "encoding"
attribute in the XML declaration is OPTIONAL if UTF-8 encoding is
used. SPPF clients and servers MUST accept a UTF-8 BOM if present,
though emitting a UTF-8 BOM is NOT RECOMMENDED.
Example XML declarations:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
9. Security Considerations
Many SPPF implementations manage data that is considered confidential
and critical. Furthermore, SPPF implementations can support
provisioning activities for multiple Registrars and Registrants. As
a result any SPPF implementation must address the requirements for
confidentiality, authentication, and authorization.
9.1. Confidentiality and Authentication
With respect to confidentiality and authentication, the transport
protocol requirements section of this document contains security
properties that the transport protocol must provide so that
authenticated endpoints can exchange data confidentially and with
integrity protection. Refer to that section and the resulting
transport protocol specification document for the specific solutions
to authentication and confidentiality.
9.2. Authorization
With respect to authorization, the SPPF server implementation must
define and implement a set of authorization rules that precisely
address (1) which Registrars will be authorized to create/modify/
delete each SPPF object type for given Registrant(s) and (2) which
Registrars will be authorized to view/get each SPPF object type for
given Registrant(s). These authorization rules are a matter of
policy and are not specified within the context of SPPF. However,
any SPPF implementation must specify these authorization rules in
order to function in a reliable and safe manner.
9.3. Denial of Service
Guidance on Denial-of-Service (DoS) issues in general is given in
[RFC4732], "Internet Denial of Service Considerations", which also
gives a general vocabulary for describing the DoS issue.
Cartwright, et al. Expires April 25, 2015 [Page 40]
Internet-Draft draft-drinks-spp-framework October 2014
SPPF is a high-level client-server protocol that can be implemented
on lower-level mechanisms such as remote procedure call and web-
service API protocols. As such, it inherits any Denial-of-Service
issues inherent to the specific lower-level mechanism used for any
implementation of SPPF. SPPF also has its own set of higher-level
exposures that are likely to be independent of lower-layer mechanism
choices.
9.3.1. DoS Issues Inherited from Transport Mechanism
SPPF implementation is in general dependent on the selection and
implementation of a lower-level transport protocol and a binding
between that protocol and SPPF. The archetypal SPPF implementation
uses XML (http://www.w3.org/TR/xml/) representation in a SOAP
(http://www.w3.org/TR/soap/) request/response framework over HTTP
([RFC7230]), and probably also uses TLS ([RFC5246]) for on-the wire
data integrity and participant authentication, and might use HTTP
Digest authentication ([RFC2609]).
The typical deployment scenario for SPPF is to have servers in a
managed facility, and therefore techniques such as Network Ingress
Filtering ([RFC2609]) are generally applicable. In short, any DoS
mechanism affecting a typical HTTP implementation would affect such
an SPPF implementation, and the mitigation tools for HTTP in general
also therefore apply to SPPF.
SPPF does not directly specify an authentication mechanism, instead
relying on the lower-level transport protocol to provide for
authentication. In general, authentication is an expensive
operation, and one apparent attack vector is to flood an SPPF server
with repeated requests for authentication, thereby exhausting its
resources. SPPF implementations SHOULD therefore be prepared to
handle authentication floods, perhaps by noting repeated failed login
requests from a given source address and blocking that source
address.
9.3.2. DoS Issues Specific to SPPF
The primary defense mechanism against DoS within SPPF is
authentication. Implementations MUST tightly control access to the
SPPF service, SHOULD implement DoS and other policy control
screening, and MAY employ a variety of policy violation reporting and
response measures such as automatic blocking of specific users and
alerting of operations personnel. In short, the primary SPPF
response to DoS-like activity by a user is to block that user or
subject their actions to additional review.
Cartwright, et al. Expires April 25, 2015 [Page 41]
Internet-Draft PCEP MIB July 2012
Domain: any collection of network elements within a common sphere of
address management or path computational responsibility.
IGP Area: OSPF Area or ISIS level.
This document also uses the terminology defined in [RFC4655] and
[RFC5440].
5. PCEP MIB Module Architecture
The PCEP MIB will contain the following information:
a. PCEP entity configuration and status.
b. PCEP peer configuration and information.
c. PCEP session configuration and information.
d. Notifications to indicate PCEP session changes.
5.1. Relations to other MIB modules
PCEP relies on existing protocols which have specialized MIB objects
to monitor their own activities. Consequently this document
considers that the monitoring underlying protocols are out of scope
of the PCEP MIB module.
6. Object Definitions
6.1. PCE-PCEP-DRAFT-MIB
This MIB module makes references to the following documents:
[RFC2578]; [RFC2579]; [RFC2580]; [RFC2863]; [RFC3411]; [RFC3813];
[RFC4001]; and [RFC4265].
PCE-PCEP-DRAFT-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
NOTIFICATION-TYPE,
Unsigned32,
Integer32,
Counter32,
experimental
FROM SNMPv2-SMI
RowStatus,
TruthValue,
Koushik, et al. Expires January 11, 2013 [Page 4]
Internet-Draft PCEP MIB July 2012
TimeStamp,
TimeInterval
FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE,
OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF
InetAddressType,
InetAddress,
InetPortNumber
FROM INET-ADDRESS-MIB;
pcePcepDraftMIB MODULE-IDENTITY
LAST-UPDATED
"201207101200Z" -- July 10, 2012
ORGANIZATION
"IETF Path Computation Element (PCE) Working Group"
CONTACT-INFO
"Email: pce@ietf.org
WG charter:
http://www.ietf.org/html.charters/pce-charter.html"
DESCRIPTION
"This MIB module defines a collection of objects for managing
PCE communication protocol (PCEP)."
::= { experimental 9999 } --
pcePcepNotifications OBJECT IDENTIFIER ::= { pcePcepDraftMIB 0 }
pcePcepMIBObjects OBJECT IDENTIFIER ::= { pcePcepDraftMIB 1 }
pcePcepConformance OBJECT IDENTIFIER ::= { pcePcepDraftMIB 2 }
pcePcepEntityObjects OBJECT IDENTIFIER ::= { pcePcepMIBObjects 1 }
--
-- PCE Entity Objects
--
pcePcepEntityLastChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the most recent
addition or deletion of an entry to/from the
pcePcepEntityTable, or the most recent change in value of
any objects in the pcePcepEntityTable.
If no such changes have occurred since the last
re-initialization of the local management subsystem,
then this object contains a zero value."
Koushik, et al. Expires January 11, 2013 [Page 5]
Internet-Draft PCEP MIB July 2012
::= { pcePcepEntityObjects 1 }
pcePcepEntityIndexNext OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains an appropriate value to be used for
pcePcepEntityIndex when creating entries in the
pcePcepEntityTable. The value 0 indicates that no unassigned
entries are available."
::= { pcePcepEntityObjects 2 }
pcePcepEntityTable OBJECT-TYPE
SYNTAX SEQUENCE OF PcePcepEntityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains information about the PCEP Entity."
::= { pcePcepEntityObjects 3 }
pcePcepEntityEntry OBJECT-TYPE
SYNTAX PcePcepEntityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table represents a PCEP entity.
An entry can be created by a network administrator
or by an SNMP agent as instructed by PCEP."
INDEX { pcePcepEntityIndex }
::= { pcePcepEntityTable 1 }
PcePcepEntityEntry ::= SEQUENCE {
pcePcepEntityIndex Integer32,
pcePcepEntityRowStatus RowStatus,
pcePcepEntityAdminStatus INTEGER,
pcePcepEntityOperStatus INTEGER,
pcePcepEntityAddrType InetAddressType,
pcePcepEntityAddr InetAddress,
pcePcepEntityTcpPort InetPortNumber,
pcePcepEntityConnectTimer Unsigned32,
pcePcepEntityOpenWaitTimer Unsigned32,
pcePcepEntityKeepWaitTimer Unsigned32,
pcePcepEntityKeepAliveTimer Unsigned32,
pcePcepEntityDeadTimer Unsigned32,
pcePcepEntitySyncTimer Unsigned32,
pcePcepEntityRequestTimer Unsigned32,
pcePcepEntityInitBackoffTimer Unsigned32,
Koushik, et al. Expires January 11, 2013 [Page 6]
Internet-Draft PCEP MIB July 2012
pcePcepEntityMaxBackoffTimer Unsigned32,
pcePcepEntityMaxSessions Unsigned32,
pcePcepEntityMaxReqPerSession Unsigned32,
pcePcepEntityMaxUnknownReqs Unsigned32,
pcePcepEntityMaxUnknownMsgs Unsigned32
}
pcePcepEntityIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This index is used to uniquely identify the PCEP entity."
::= { pcePcepEntityEntry 1 }
pcePcepEntityRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row."
::= { pcePcepEntityEntry 2 }
pcePcepEntityAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
adminStatusUp(1),
adminStatusDown(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The administrative status of this PCEP Entity. If this
object is changed from 'up' to 'down' and this entity has
already attempted to establish contact with a Peer, then all
contact with that Peer is lost."
DEFVAL { adminStatusDown }
::= { pcePcepEntityEntry 3 }
pcePcepEntityOperStatus OBJECT-TYPE
SYNTAX INTEGER {
operStatusUp(1), -- active
operStatusDown(2), -- inactive
operStatusGoingUp(3), -- activating
operStatusGoingDown(4), -- deactivating
operStatusFailed(5), -- failed, will recover
-- when possible
operStatusFailedPerm(6) -- operator intervention
Koushik, et al. Expires January 11, 2013 [Page 7]
Internet-Draft PCEP MIB July 2012
-- required
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The operational status of the PCEP entity."
::= { pcePcepEntityEntry 4 }
pcePcepEntityAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of the PCEP entity's Internet address. This object
specifies how the value of the pcePcepPeerAddr object should
be interpreted."
::= { pcePcepEntityEntry 5 }
pcePcepEntityAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Internet address of this PCEP entity. The type is given
by pcePcepEntityAddrType.
If operating as a PCE server, the PCEP entity listens on
this address. If operating as a PCC, the PCEP entity binds
outgoing TCP connections to this address."
::= { pcePcepEntityEntry 6 }
pcePcepEntityTcpPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The TCP Port for PCEP. The default value is the well-known
value of this port."
DEFVAL { 4189 }
::= { pcePcepEntityEntry 7 }
pcePcepEntityConnectTimer OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
Koushik, et al. Expires January 11, 2013 [Page 8]
Internet-Draft PCEP MIB July 2012
"The time that the PCEP entity will wait to establish a TCP
connection with a PCEP peer. If a TCP connection is not
established within this time then PCEP aborts the session
setup attempt."
DEFVAL { 60 }
::= { pcePcepEntityEntry 8 }
pcePcepEntityOpenWaitTimer OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The time that the PCEP entity will wait to receive an Open
message from a PCEP peer. If no Open message is received
within this time then PCEP aborts the session setup attempt."
DEFVAL { 60 }
::= { pcePcepEntityEntry 9 }
pcePcepEntityKeepWaitTimer OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The time that the PCEP entity will wait to receive a
Keepalive or PCErr message from a PCEP peer during session
initialization. If no Keepalive or PCErr message is received
within this time then PCEP aborts the session setup attempt."
DEFVAL { 60 }
::= { pcePcepEntityEntry 10 }
pcePcepEntityKeepAliveTimer OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The keep alive transmission timer that this PCEP entity will
propose in the initial OPEN message of each session it is
involved in. This is the maximum time between two
consecutive messages sent to a PCEP peer. Zero means that
the PCEP entity prefers not to send Keepalives at all.
Note that the actual Keepalive transmission intervals, in
either direction of an active PCEP session, are determined
by negotiation between the PCEP peers as specified by RFC
5440, and so may differ from this configured value. For
Koushik, et al. Expires January 11, 2013 [Page 9]
Internet-Draft PCEP MIB July 2012
the actually negotiated values (per-session), see
pcePcepSessionKeepaliveTimer and
pcePcepSessionPeerKeepaliveTimer."
DEFVAL { 30 }
::= { pcePcepEntityEntry 11 }
pcePcepEntityDeadTimer OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The dead timer that this PCEP entity will propose in the
initial OPEN message of each session it is involved in.
This is the time after which a PCEP peer should declare a
session down if it does not receive any PCEP messages.
pcePcepEntityDeadTimer is recommended to be 4 times the
pcePcepEntityKeepAliveTimer value. Zero means suggesting
that the peer does not run a dead timer at all; it is only
allowed when pcePcepEntityKeepAliveTimer is also zero."
DEFVAL { 120 }
::= { pcePcepEntityEntry 12 }
pcePcepEntitySyncTimer OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
&Internet-Draft draft-drinks-spp-framework October 2014
SPPF allows a client to submit multiple-element or "batch" requests
that may insert or otherwise affect a large amount of data with a
single request. In the simplest case, the server progresses
sequentially through each element in a batch, completing one and
before starting the next. Mid-batch failures are handled by stopping
the batch and rolling-back the data store to its pre-request state.
This "stop and roll-back" design provides a DoS opportunity. A
hostile client could repeatedly issue large batch requests with one
or more failing elements, causing the server to repeatedly stop and
roll-back large transactions. The suggested response is to monitor
clients for such failures, and take administrative action (such as
blocking the user) when an excessive number of roll-backs is
reported.
An additional suggested response is for an implementer to set their
maximum allowable XML message size, and their maximum allowable batch
size at a level that they feel protects their operational instance,
given the hardware sizing they have in place and the expected load
and size needs that their users expect.
9.4. Information Disclosure
It is not uncommon for the logging systems to document on-the-wire
messages for various purposes, such as, debug, audit, and tracking.
At the minimum, the various support and administration staff will
have access to these logs. Also, if an unprivileged user gains
access to the SPPF deployments and/or support systems, it will have
access to the information that is potentially deemed confidential.
To manage information disclosure concerns beyond the transport level,
SPPF implementations MAY provide support for encryption at the SPPF
object level.
9.5. Non Repudiation
In some situations, it may be required to protect against denial of
involvement (see [RFC4949]) and tackle non-repudiation concerns in
regards to SPPF messages. This type of protection is useful to
satisfy authenticity concerns related to SPPF messages beyond the
end-to-end connection integrity, confidentiality, and authentication
protection that the transport layer provides. This is an optional
feature and some SPPF implementations MAY provide support for it.
9.6. Replay Attacks
Anti-replay protection ensures that a given SPPF object replayed at a
later time doesn't affect the integrity of the system. SPPF provides
at least one mechanism to fight against replay attacks. Use of the
optional client transaction identifier allows the SPPF client to
Cartwright, et al. Expires April 25, 2015 [Page 42]
Internet-Draft draft-drinks-spp-framework October 2014
correlate the request message with the response and to be sure that
it is not a replay of a server response from earlier exchanges. Use
of unique values for the client transaction identifier is highly
encouraged to avoid chance matches to a potential replay message.
9.7. Man in the Middle
The SPPF client or Registrar can be a separate entity acting on
behalf of the Registrant in facilitating provisioning transactions to
the Registry. Further, the transport layer provides end-to-end
connection protection between SPPF client and the SPPF server.
Therefore, man-in-the-middle attack is a possibility that may affect
the integrity of the data that belongs to the Registrant and/or
expose peer data to unintended actors in case well-established
peering relationships already exist.
10. Internationalization Considerations
Character encodings to be used for SPPF elements are described in
Section 8.2. The use of time elements in the protocol is specified
in Section 3.2. Where human-readable languages are used in the
protocol, those messages SHOULD be tagged according to [RFC5646], and
the transport protocol MUST support a respective mechanism to
transmit such tags together with those human-readable messages. If
tags are absent, the language of the message defaults to "en"
(English).
11. IANA Considerations
11.1. URN Assignments
This document uses URNs to describe XML namespaces and XML schemas
conforming to a Registry mechanism described in [RFC3688].
Two URI assignments are requested.
Registration request for the SPPF XML namespace:
urn:ietf:params:xml:ns:sppf:base:1
Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the XML schema:
URI: urn:ietf:params:xml:schema:sppf:1
Registrant Contact: IESG
XML: See the "Formal Specification" section of this document
(Section 12).
Cartwright, et al. Expires April 25, 2015 [Page 43]
Internet-Draft draft-drinks-spp-framework October 2014
11.2. Organization Identifier Namespace Registry
IANA is requested to create and maintain a Registry entitled "SPPF
OrgIdType Namespaces". Strings used as OrgIdType Namespace
identifiers MUST conform to the following syntax in the Augmented
Backus-Naur Form (ABNF) [RFC5234]
namespace = ALPHA * (ALPHA/DIGIT/"-")
Assignments consist of the OrgIdType namespace string, and the
definition of the associated namespace. This document makes the
following initial assignment for the OrgIdType Namespaces:
OrgIdType namespace string Namespace
-------------------------- ---------
IANA Enterprise Numbers iana-en
Future assignments are to be made through the well known IANA Policy
"RFC Required" (see section 4.1 of [RFC5226])
12. Formal Specification
This section provides the draft XML Schema Definition for SPPF
Protocol.
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:sppf:base:1"
elementFormDefault="qualified" xml:lang="EN">
<annotation>
<documentation>
---- Generic Object key types to be defined by specific
Transport/Architecture. The types defined here can
be extended by the specific architecture to
define the Object Identifiers ----
</documentation>
</annotation>
<complexType name="ObjKeyType"
abstract="true">
<annotation>
<documentation>
---- Generic type that represents the
key for various objects in SPPF. ----
</documentation>
</annotation>
</complexType>
Cartwright, et al. Expires April 25, 2015 [Page 44]
Internet-Draft draft-drinks-spp-framework October 2014
<complexType name="SedGrpOfferKeyType" abstract="true">
<complexContent>
<extension base="sppfb:ObjKeyType">
<annotation>
<documentation>
---- Generic type that represents
the key for a SED group offer. ----
</documentation>
</annotation>
</extension>
</complexContent>
</complexType>
<complexType name="PubIdKeyType" abstract="true">
<complexContent>
<extension base="sppfb:ObjKeyType">
<annotation>
<documentation>
----Generic type that
represents the key
for a Pub Id. ----
</documentation>
</annotation>
</extension>
</complexContent>
</complexType>
<annotation>
<documentation>
---- Object Type Definitions ----
</documentation>
</annotation>
<complexType name="SedGrpType">
<complexContent>
<extension base="sppfb:BasicObjType">
<sequence>
<element name="sedGrpName" type="sppfb:ObjNameType"/>
<element name="sedRecRef" type="sppfb:SedRecRefType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="dgName" type="sppfb:ObjNameType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="peeringOrg" type="sppfb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="sourceIdent" type="sppfb:SourceIdentType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="isInSvc" type="boolean"/>
<element name="priority" type="unsignedShort"/>
Cartwright, et al. Expires April 25, 2015 [Page 45]
Internet-Draft draft-drinks-spp-framework October 2014
<element name="ext"
type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DestGrpType">
<complexContent>
<extension base="sppfb:BasicObjType">
<sequence>
<element name="dgName"
type="sppfb:ObjNameType"/"The value of SYNC timer is used in the case of synchronized
path computation request using the SVEC object.
Consider the case where a PCReq message is received by a PCE
that contains the SVEC object referring to M synchronized
path computation requests. If after the expiration of the
SYNC timer all the M path computation requests have not been
received, a protocol error is triggered and the PCE MUST
cancel the whole set of path computation requests.
The aim of the SyncTimer is to avoid the storage of unused
synchronized request should one of them get lost for some
reasons (for example, a misbehaving PCC)."
DEFVAL { 60 }
::= { pcePcepEntityEntry 13 }
pcePcepEntityRequestTimer OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
Koushik, et al. Expires January 11, 2013 [Page 10]
Internet-Draft PCEP MIB July 2012
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum time that the PCEP entity will wait for a
response to a PCReq message."
DEFVAL { 60 }
::= { pcePcepEntityEntry 14 }
pcePcepEntityInitBackoffTimer OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The initial back-off time for retrying a failed session
setup attempt to a peer.
The back-off time doubles for each failed session setup
attempt, until a maximum back-off time is reached. The
maximum back-off time is configured in
pcePcepEntityMaxBackoffTimer."
DEFVAL { 60 }
::= { pcePcepEntityEntry 15 }
pcePcepEntityMaxBackoffTimer OBJECT-TYPE
SYNTAX Unsigned32 (1..604800)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum back-off time for retrying a failed session
setup attempt to a peer.
The back-off time doubles for each failed session setup
attempt, until this maximum value is reached. Session
setup attempts then repeat periodically without any
further increase in back-off time.
The value of pcePcepEntityMaxBackoffTimer must be greater
than or equal to pcePcepEntityInitBackoffTimer."
DEFVAL { 600 }
::= { pcePcepEntityEntry 16 }
pcePcepEntityMaxSessions OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
Koushik, et al. Expires January 11, 2013 [Page 11]
Internet-Draft PCEP MIB July 2012
DESCRIPTION
"Maximum number of sessions involving this PCEP entity
that can exist at any time."
DEFVAL { 100 }
::= { pcePcepEntityEntry 17 }
pcePcepEntityMaxReqPerSession OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Maximum number of independent requests sent to a peer that
can be outstanding at any time.
Once a PCEP entity has this number of requests outstanding
on a session, it MUST wait to receive responses before
sending any further requests on the session."
DEFVAL { 100 }
::= { pcePcepEntityEntry 18 }
pcePcepEntityMaxUnknownReqs OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum number of unrecognized requests and replies that
any session on this PCEP entity is willing to accept per
minute.
A PCRep message contains an unrecognized reply if it
contains an RP object whose request ID does not correspond
to any in-progress request sent by this PCEP entity.
A PCReq message contains an unrecognized request if it
containd an RP object whose request ID is zero."
DEFVAL { 5 }
::= { pcePcepEntityEntry 19 }
pcePcepEntityMaxUnknownMsgs OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum number of unknown messages that any session
on this PCEP entity is willing to accept per minute."
DEFVAL { 5 }
::= { pcePcepEntityEntry 20 }
Koushik, et al. Expires January 11, 2013 [Page 12]
Internet-Draft PCEP MIB July 2012
--
-- The PCEP Peer Table
--
pcePcepPeerObjects OBJECT IDENTIFIER ::= { pcePcepMIBObjects 2 }
pcePcepPeerTable OBJECT-TYPE
SYNTAX SEQUENCE OF PcePcepPeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about PCEP peers known by Entities in the
pcePcepEntityTable.
This MIB table gives PCEP peer information that spans PCEP
sessions. Information about current PCEP sessions can be
found in the pcePcepSessionTable MIB table."
::= { pcePcepPeerObjects 1 }
pcePcepPeerEntry OBJECT-TYPE
SYNTAX PcePcepPeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a single PCEP Peer which spans all PCEP
sessions to that peer. The information contained in a row
is read-only."
INDEX { pcePcepEntityIndex,
pcePcepPeerAddrType,
pcePcepPeerAddr }
::= { pcePcepPeerTable 1 }
PcePcepPeerEntry ::= SEQUENCE {
pcePcepPeerAddrType InetAddressType,
pcePcepPeerAddr InetAddress,
pcePcepPeerSessionExists TruthValue,
pcePcepPeerNumSessSetupOK Counter32,
pcePcepPeerNumSessSetupFail Counter32,
pcePcepPeerSessionUpTime TimeStamp,
pcePcepPeerSessionFailTime TimeStamp,
pcePcepPeerResponseTime Unsigned32
}
pcePcepPeerAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Koushik, et al. Expires January 11, 2013 [Page 13]
Internet-Draft PCEP MIB July 2012
"The peer Internet address type (IPv4 or IPv6).
This specifies how the pcePcepPeerAddr value should be
interpreted."
::= { pcePcepPeerEntry 2 }
pcePcepPeerAddr OBJECT-TYPE
SYNTAX InetAddress (SIZE (4..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Internet address of the peer.
The type of this address is specified by the
pcePcepPeerAddrType value."
::= { pcePcepPeerEntry 3 }
pcePcepPeerSessionExists OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates whether a session with this peer currently
exists."
::= { pcePcepPeerEntry 4 }
pcePcepPeerNumSessSetupOK OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PCEP sessions successfully established with
the peer, including any current session."
::= { pcePcepPeerEntry 5 }
pcePcepPeerNumSessSetupFail OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PCEP sessions with the peer that failed before
reaching session state pceSessionUp."
::= { pcePcepPeerEntry 6 }
pcePcepPeerSessionUpTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
Koushik, et al. Expires January 11, 2013 [Page 14]
Internet-Draft PCEP MIB July 2012
DESCRIPTION
"The value of sysUpTime the last time a session with this
peer was successfully established.
If pcePcepPeerSessionUpCount is zero, then this object
contains zero."
::= { pcePcepPeerEntry 7 }
pcePcepPeerSessionFailTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime the last time a session with this
peer failed to be established.
If pcePcepPeerSessionFailCount is zero, then this object
contains zero."
::= { pcePcepPeerEntry 8 }
pcePcepPeerResponseTime OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The average response time for this peer.
If an average response time has not been calculated for this
peer then this object has the value zero."
::= { pcePcepPeerEntry 9 }
--
-- The PCEP Sessions Table
--
pcePcepSessionObjects OBJECT IDENTIFIER ::= { pcePcepMIBObjects 3 }
pcePcepSessionTable OBJECT-TYPE
SYNTAX SEQUENCE OF PcePcepSessionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of Sessions on this PCEP entity. Each row in this
table represents a single session."
::= { pcePcepSessionObjects 1 }
pcePcepSessionEntry OBJECT-TYPE
Koushik, et al. Expires January 11, 2013 [Page 15]
Internet-Draft PCEP MIB July 2012
SYNTAX PcePcepSessionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table represents information on a
single session between two PCEP clients. The information
contained in a row is read-only."
INDEX { pcePcepEntityIndex,
pcePcepPeerAddrType,
pcePcepPeerAddr }
::= { pcePcepSessionTable 1 }
PcePcepSessionEntry ::= SEQUENCE {
pcePcepSessionStateLastChange TimeStamp,
pcePcepSessionState INTEGER,
pcePcepSessionLocalID Integer32,
pcePcepSessionPeerID Integer32,
pcePcepSessionKeepaliveTimer Unsigned32,
pcePcepSessionPeerKeepaliveTimer Unsigned32,
pcePcepSessionDeadTimer Unsigned32,
pcePcepSessionPeerDeadTimer Unsigned32,
pcePcepSessionKAHoldTimeRem TimeInterval,
pcePcepSessionNumPCReqSent Counter32,
pcePcepSessionNumPCReqRcvd Counter32,
pcePcepSessionNumPCRepSent Counter32,
pcePcepSessionNumPCRepRcvd Counter32,
pcePcepSessionNumPCErrSent Counter32,
pcePcepSessionNumPCErrRcvd Counter32,
pcePcepSessionNumPCNtfSent Counter32,
pcePcepSessionNumPCNtfRcvd Counter32,
pcePcepSessionNumKeepaliveSent Counter32,
pcePcepSessionNumKeepaliveRcvd Counter32,
pcePcepSessionNumUnknownRcvd Counter32
}
pcePcepSessionStateLastChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time this session entered its
current state as denoted by the pcePcepSessionState object."
::= { pcePcepSessionEntry 1 }
pcePcepSessionState OBJECT-TYPE
SYNTAX INTEGER {
idle(0),
tcpPending(1),
Koushik, et al. Expires January 11, 2013 [Page 16]
Internet-Draft PCEP MIB July 2012
openWait(2),
keepWait(3),
sessionUp(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current state of the session."
::= { pcePcepSessionEntry 2 }
pcePcepSessionLocalID OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of the PCEP session ID used by the local PCEP
speaker in the Open message for this session."
::= { pcePcepSessionEntry 3 }
pcePcepSessionPeerID OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of the PCEP session ID used by the peer in its
Open message for this session."
::= { pcePcepSessionEntry 4 }
pcePcepSessionKeepaliveTimer OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The agreed maximum interval at which the local PCEP speaker
transmits PCEP messages on this PCEP session. Zero means
that the local PCEP speaker never sends Keepalives on this
session."
::= { pcePcepSessionEntry 5 }
pcePcepSessionPeerKeepaliveTimer OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The agreed maximum interval at which the peer transmits PCEP
messages on this PCEP session. Zero means that the peer
never sends Keepalives on this session."
::= { pcePcepSessionEntry 6 }
Koushik, et al. Expires January 11, 2013 [Page 17]
Internet-Draft PCEP MIB July 2012
pcePcepSessionDeadTimer OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local PCEP speaker's DeadTimer interval for this PCEP
session."
::= { pcePcepSessionEntry 7 }
pcePcepSessionPeerDeadTimer OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The peer's DeadTimer interval for for this PCEP session."
::= { pcePcepSessionEntry 8 }
pcePcepSessionKAHoldTimeRem OBJECT-TYPE
SYNTAX TimeInterval
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The keep alive hold time remaining for this session."
::= { pcePcepSessionEntry 9 }
pcePcepSessionNumPCReqSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PCReq messages sent on this session."
::= { pcePcepSessionEntry 10 }
pcePcepSessionNumPCReqRcvd OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PCReq messages received on this session."
::= { pcePcepSessionEntry 11 }
pcePcepSessionNumPCRepSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PCRep messages sent on this session."
::= { pcePcepSessionEntry 12 }
gt;
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="PubIdType" abstract="true">
<complexContent>
<extension base="sppfb:BasicObjType">
<sequence>
<element name="dgName" type="sppfb:ObjNameType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="TNType">
<complexContent>
<extension base="sppfb:PubIdType">
<sequence>
<element name="tn" type="sppfb:NumberValType"/>
<element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
<element name="sedRecRef" type="sppfb:SedRecRefType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="TNRType">
<complexContent>
<extension base="sppfb:PubIdType">
<sequence>
<element name="range" type="sppfb:NumberRangeType"/>
<element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Cartwright, et al. Expires April 25, 2015 [Page 46]
Internet-Draft draft-drinks-spp-framework October 2014
<complexType name="TNPType">
<complexContent>
<extension base="sppfb:PubIdType">
<sequence>
<element name="tnPrefix" type="sppfb:NumberValType"/>
<element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="RNType">
<complexContent>
<extension base="sppfb:PubIdType">
<sequence>
<element name="rn" type="sppfb:NumberValType"/>
<element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name=&Koushik, et al. Expires January 11, 2013 [Page 18]
Internet-Draft PCEP MIB July 2012
pcePcepSessionNumPCRepRcvd OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PCRep messages received on this session."
::= { pcePcepSessionEntry 13 }
pcePcepSessionNumPCErrSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PCErr messages sent on this session."
::= { pcePcepSessionEntry 14 }
pcePcepSessionNumPCErrRcvd OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PCErr messages received on this session."
::= { pcePcepSessionEntry 15 }
pcePcepSessionNumPCNtfSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PCNtf messages sent on this session."
::= { pcePcepSessionEntry 16 }
pcePcepSessionNumPCNtfRcvd OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of PCNtf messages received on this session."
::= { pcePcepSessionEntry 17 }
pcePcepSessionNumKeepaliveSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Keepalive messages sent on this session."
::= { pcePcepSessionEntry 18 }
Koushik, et al. Expires January 11, 2013 [Page 19]
Internet-Draft PCEP MIB July 2012
pcePcepSessionNumKeepaliveRcvd OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Keepalive messages received on this session."
::= { pcePcepSessionEntry 19 }
pcePcepSessionNumUnknownRcvd OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of unknown messages received on this session."
::= { pcePcepSessionEntry 20 }
---
--- Notifications
---
pcePcepSessionUp NOTIFICATION-TYPE
OBJECTS {
pcePcepSessionState,
pcePcepSessionStateLastChange
}
STATUS current
DESCRIPTION
"This notification is sent when the value of
'pcePcepSessionState' enters the 'sessionUp(4)' state."
::= { pcePcepNotifications 1 }
pcePcepSessionDown NOTIFICATION-TYPE
OBJECTS {
pcePcepSessionState,
pcePcepSessionStateLastChange
}
STATUS current
DESCRIPTION
"This notification is sent when the value of
'pcePcepSessionState' leaves the 'sessionUp(4)' state."
::= { pcePcepNotifications 2 }
--
-- Module Conformance Statement
--
pcePcepGroups
OBJECT IDENTIFIER ::= { pcePcepConformance 1 }
Koushik, et al. Expires January 11, 2013 [Page 20]
Internet-Draft PCEP MIB July 2012
pcePcepCompliances
OBJECT IDENTIFIER ::= { pcePcepConformance 2 }
--
-- Full Compliance
--
pcePcepModuleFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The Module is implemented with support for read-create. In
other words, both monitoring and configuration are available
when using this MODULE-COMPLIANCE."
MODULE -- this module
MANDATORY-GROUPS { pcePcepGeneralGroup,
pcePcepNotificationsGroup
}
::= { pcePcepCompliances 1 }
--
-- Read-Only Compliance
--
pcePcepModuleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The Module is implemented with support for read-only. In
other words, only monitoring is available by implementing
this MODULE-COMPLIANCE."
MODULE -- this module
MANDATORY-GROUPS { pcePcepGeneralGroup,
pcePcepNotificationsGroup
}
::= { pcePcepCompliances 2 }
-- units of conformance
pcePcepGeneralGroup OBJECT-GROUP
OBJECTS { pcePcepEntityLastChange,
pcePcepEntityIndexNext,
pcePcepEntityRowStatus,
pcePcepEntityAdminStatus,
pcePcepEntityOperStatus,
pcePcepEntityAddrType,
Koushik, et al. Expires January 11, 2013 [Page 21]
Internet-Draft PCEP MIB July 2012
pcePcepEntityAddr,
pcePcepEntityTcpPort,
pcePcepEntityConnectTimer,
pcePcepEntityOpenWaitTimer,
pcePcepEntityKeepWaitTimer,
pcePcepEntityKeepAliveTimer,
pcePcepEntityDeadTimer,
pcePcepEntitySyncTimer,
pcePcepEntityRequestTimer,
pcePcepEntityInitBackoffTimer,
pcePcepEntityMaxBackoffTimer,
pcePcepEntityMaxSessions,
pcePcepEntityMaxReqPerSession,
pcePcepEntityMaxUnknownReqs,
pcePcepEntityMaxUnknownMsgs,
pcePcepPeerSessionExists,
pcePcepPeerNumSessSetupOK,
pcePcepPeerNumSessSetupFail,
pcePcepPeerSessionUpTime,
pcePcepPeerSessionFailTime,
pcePcepPeerResponseTime,
pcePcepSessionStateLastChange,
pcePcepSessionState,
pcePcepSessionLocalID,
pcePcepSessionPeerID,
pcePcepSessionKeepaliveTimer,
pcePcepSessionPeerKeepaliveTimer,
pcePcepSessionDeadTimer,
pcePcepSessionPeerDeadTimer,
pcePcepSessionKAHoldTimeRem,
pcePcepSessionNumPCReqSent,
pcePcepSessionNumPCReqRcvd,
pcePcepSessionNumPCRepSent,
pcePcepSessionNumPCRepRcvd,
pcePcepSessionNumPCErrSent,
pcePcepSessionNumPCErrRcvd,
pcePcepSessionNumPCNtfSent,
pcePcepSessionNumPCNtfRcvd,
pcePcepSessionNumKeepaliveSent,
pcePcepSessionNumKeepaliveRcvd,
pcePcepSessionNumUnknownRcvd
}
STATUS current
DESCRIPTION
"Objects that apply to all PCEP MIB implementations."
::= { pcePcepGroups 1 }
Koushik, et al. Expires January 11, 2013 [Page 22]
Internet-Draft PCEP MIB July 2012
pcePcepNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { pcePcepSessionUp,
pcePcepSessionDown
}
STATUS current
DESCRIPTION
"The notifications for a PCEP MIB implementation."
::= { pcePcepGroups 2 }
END
7. Security Considerations
This MIB module can be used for configuration of certain objects, and
anything that can be configured can be incorrectly configured, with
potentially disastrous results.
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-create. Such objects may be
considered sensitive or vulnerable in some network environments. The
support for SET operations in a non-secure environment without proper
protection can have a negative effect on network operations. These
are the tables and objects and their sensitivity/vulnerability:
o pcePcepEnityTcpPort: A PCC or PCE listening in on the wrong TCP
port would mean PCEP communications would fail.
o pcePcepEntityKeepAliveTimer: Changing the PCEP session keepalive
timer to a value lower than the default value, may force premature
PCEP communication time-outs.
o pcePcepEntityRowStatus: Setting row status incorrectly may turn
off the PCEP client.
o pcePcepEntityDeadTimer: Changing the PCEP session deadtimer timer
to a value lower than the default value, may force premature PCEP
communication time-outs.
The user of the PCE-PCEP-DRAFT-MIB module must therefore be aware
that support for SET operations in a non-secure environment without
proper protection can have a negative effect on network operations.
The readable objects in the PCE-PCEP-DRAFT-MIB module (i.e., those
with MAX-ACCESS other than not-accessible) may be considered
sensitive in some environments since, collectively, they provide
information about the amount and frequency of path computation
requests and responses within the network and can reveal some aspects
of their configuration.
Koushik, et al. Expires January 11, 2013 [Page 23]
Internet-Draft PCEP MIB July 2012
In such environments it is important to control also GET and NOTIFY
access to these objects and possibly even to encrypt their values
when sending them over the network via SNMP.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPsec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
8. IANA Considerations
IANA is requested to make a MIB OID assignment for pceStdMIB under
the mib-2 branch. The MIB module in this document uses the following
IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers
registry:
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
pceStdMIB { mib-2 XXX }
IANA is requested to root MIB objects in the MIB module contained in
this document under the mib-2 subtree.
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.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Koushik, et al. Expires January 11, 2013 [Page 24]
Internet-Draft PCEP MIB July 2012
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB)", RFC 3813,
June 2004.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
[RFC4265] Schliesser, B. and T. Nadeau, "Definition of Textual
Conventions for Virtual Private Network (VPN) Management",
RFC 4265, November 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
9.2. Normative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Koushik, et al. Expires January 11, 2013 [Page 25]
Internet-Draft PCEP MIB July 2012
Appendix A. Acknowledgement
The authors would like to thank Santanu Mazumder and Meral
Shirazipour for their valuable input.
Funding for the RFC Editor function is currently provided by the
Internet Society.
Authors' Addresses
A S Kiran Koushik
Cisco Systems, Inc.
EMail: kkoushik@cisco.com
Stephan Emile
France Telecom
2 avenue Pierre Marzin
Lannion F-22307
France
EMail: emile.stephan@orange-ftgroup.com
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
EMail: qzhao@huawei.com
Daniel King
Old Dog Consulting
UK
EMail: daniel@olddog.co.uk
Koushik, et al. Expires January 11, 2013 [Page 26]
Internet-Draft PCEP MIB July 2012
quot;URIPubIdType">
<complexContent>
<extension base="sppfb:PubIdType">
<sequence>
<element name="uri" type="anyURI"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="SedRecType" abstract="true">
<complexContent>
<extension base="sppfb:BasicObjType">
<sequence>
<element name="sedName" type="sppfb:ObjNameType"/>
<element name="sedFunction" type="sppfb:SedFunctionType"
minOccurs="0"/>
<element name="isInSvc" type="boolean"/>
<element name="ttl" type="positiveInteger" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="NAPTRType">
<complexContent>
<extension base="sppfb:SedRecType">
<sequence>
<element name="order" type="unsignedShort"/>
Cartwright, et al. Expires April 25, 2015 [Page 47]
Internet-Draft draft-drinks-spp-framework October 2014
<element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
<element name="svcs" type="sppfb:SvcType"/>
<element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
<element name="repl" type="sppfb:ReplType" minOccurs="0"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="NSType">
<complexContent>
<extension base="sppfb:SedRecType">
<sequence>
<element name="hostName" type="token"/>
<element name="ipAddr" type="sppfb:IPAddrType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="URIType">
<complexContent>
<extension base="sppfb:SedRecType">
<sequence>
<element name="ere" type="token" default="^(.*)$"/>
<element name="uri" type="anyURI"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="SedGrpOfferType">
<complexContent>
<extension base="sppfb:BasicObjType">
<sequence>
<element name="sedGrpOfferKey" type="sppfb:SedGrpOfferKeyType"/>
<element name="status" type="sppfb:SedGrpOfferStatusType"/>
<element name="offerDateTime" type="dateTime"/>
<element name="acceptDateTime&Jonathan Hardwick
Metaswitch
100 Church Street
Enfield EN2 6BQ
UK
EMail: jon.hardwick@metaswitch.com
Koushik, et al. Expires January 11, 2013 [Page 27]