WG: Resource Allocation Protocol (RAP) Gino Carrozzo Internet Draft Nicola Ciulli Giacomo Sergio Document: draft-cpr-rap-cops-maid-00.txt CPR Expires: April 2004 November 2003 COPS-MAID: COPS Usage for Multi-Access Inter-Domain MPLS-DiffServ Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes an architecture for the communication between Border Routers (BR) and a Bandwidth Broker (BB) in a MPLS/DiffServ core network. This architecture is based on the Common Open Policy Service (COPS) protocol and defines a new Client Type extension for it. This specification applies basically to intra-domain MPLS/DiffServ network scenarios. However, the same extensions to COPS are suitable for inter-domain communications, when MPLS Label Switched Paths (LSP) with QoS-DiffServ guarantees are established across multiple MPLS/DiffServ islands. Therefore, this document provides also a simple and efficient model for inter-BB communication. Carrozzo, et al. Expires û April 2004 [Page 1] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 The new COPS client type provides a unified semantic to unify the specific parameters of the different access protocols towards the Policy Decision Point (PDP) on the BB, allowing the use of a single PEP type implementation despite of the adopted access protocol. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Network Model..................................................3 2. COPS-MAID extensions...........................................5 2.1 Client Type................................................5 2.2 Context Object.............................................5 2.3 COPS-MAID Protocol Objects Format..........................6 2.4 Request ID Object..........................................6 2.5 Source Host IPv4 address Object............................7 2.6 Destination IPv4 address Object............................7 2.7 Source Host IPv6 address Object............................7 2.8 Destination IPv6 address Object............................8 2.9 IPv4 Ingress Border Router Interface Object/TrunkID........8 2.10 IPv6 Ingress Border Router Interface Object/TrunkID.......9 2.11 Egress Border Router Interface Object.....................9 2.12 IPv6 Egress Border Router Interface Object...............10 2.13 Traffic Type Object......................................10 2.14 Traffic Characterization Object..........................11 2.15 QoS Class Description Object.............................15 2.16 QoS Parameters Description Object........................15 2.17 LSP Recovery description Object..........................16 2.18 COPS-MAID Decision Object................................17 2.19 Temporal information object..............................17 2.20 Explicit Route object....................................18 2.21 Reject Reason Object.....................................21 3. COPS-MAID Client Specific Information Object..................21 3.1 COPS-MAID Client Specific RAR data........................21 3.2 COPS-MAID Client Specific Decision data...................22 4. Message content...............................................23 4.1 Request Message (REQ) PEP -> PDP..........................23 4.2 Decision Message (DEC) PDP -> PEP.........................23 4.3 Report State Message (RPT) PEP -> PDP.....................23 Security Considerations..........................................23 References.......................................................24 Acknowledgments..................................................24 Author's Addresses...............................................24 Carrozzo, et al. Expires - Aprily 2004 [Page 2] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 1. Network Model COPS (Common Open Policy Service) [3]is a simple query and response protocol that can be used to exchange policy information in an administrative domain. Relying on the client-server model, COPS architecture is based on two fundamental elements: a policy server, called Policy Decision Point (PDP), also addressed as COPS server, and one or more policy clients, called Policy Enforcement Points (PEPs), addressed as COPS clients. At least one policy server must exist in each administrative domain, in order to implement a complete COPS communication with one or more PEPs. A single PEP is able to support multiple client-types, and it may send multiple Client-Open messages to the PDP, each specifying a particular client-type to a PDP over one or more TCP connections. If a client-type is not supported by the PDP, the PDP itself can redirect the PEP to an alternative PDP address and port for a given client-type via COPS. In an advisable network scenario the peripheral non-DiffServ access networks (IntServ networks with the RSVP, H.323, SIP, MPEG-4, etc.) are connected to a MPLS/DiffServ core network. In such a network ERs and BRs manage the interoperability between different domains: in our proposal the functionality of both devices are unified in a single element called MA-BR, where MA identifies a generic Multi-Access network architecture. The data plane provides the mapping and forwarding of the access network flows into the proper DiffServ PHBs/LSPs(labels) and vice versa. The control plane is responsible for Admission Control (AC) and policy decisions (taken on a per-flow or per-PHB basis) and for the service level agreement (SLA) maintenance. Our proposal for such a control plane is to provide the MA-BR communication with BB by means of the COPS protocol, because of the great flexibility it provides and of the encapsulation capability for client-specific information in COPS messages. The MA-BR may either delegate all AC and policy decisions to the BB, working in a totally outsourcing scenario, or may have limited local AC and policy functionality, granted by a provisioning scenario. In any case BB has pre-emption rights on each MA-BR decision. According to the COPS architecture [3], the MA-BR must provide an interface to the BB (i.e. the COPS client, or PEP) to send requests, accept decisions and periodically report its status. The BB, which is able to monitor the network status works as an "oracle", performs the centralized AC and policy functionality. It is possible (e.g. in MPLS Core Networks) that the BB configures core and border elements according to its choices, achieving traffic engineering capabilities. The BB, in its turn, must provide the MA-BR with an interface to accept requests and send decisions (i.e. the PDP, or COPS server) and should have one or more interfaces towards the core network, in order to collect statistics and configure the devices. Carrozzo, et al. Expires - Aprily 2004 [Page 3] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 As previously addressed, it is desirable to tune an optimum mix of dynamical and static resource allocation in order to share architectural complexity between BB module and border NEs and make the system scalable. Our proposal focuses on the possibility of integrating different protocols used in the access network. In a general scenario, applications speaking different signalling protocols may coexist, and the access point of the Core Network, i.e. the MA-BR, must understand all these languages. According to the COPS architecture, different applications using different protocols may be viewed as different client types. A client type is already defined for the integration of RSVP and COPS [4], where RSVP is COPS client-type 1. The proposed standard has some weak points due to the nature of RSVP itself, e.g. the duplication of the states installed both in PDP and in PEP which limits the scalability of the model and the possibility of expanding the core domain. A possible solution to this scalability problem is an administrative domain with many PDP supporting one or few client- types each. Whenever a PEP sends a client-open message to a PDP, that does not support that client-type, it has the capability to redirect the PEP to the right PDP. This solution is more scalable but needs to implement many COPS servers, one for each of the supported client- types within the domain. All these COPS servers have to exchange management information to perform a coherent resource allocation, or they must query for a higher level "omniscient" BB. We propose to develop a unified COPS semantic in order to integrate all the different protocols supported by the access domain. This semantic will encapsulate the client-specific information in a common format besides of the specific protocol. By means of this modified architecture it is possible to reduce the complexity of the system. The MA-BR traduces the incoming requests in a common format: - a unified COPS client-type transmits all the information to the PDP; - it is no longer needed to develop a different COPS server (PDP) for each supported COPS client; - there is no need to refer to a higher-level device when performing resource allocation because the unique COPS server (PDP) could be located inside the BB itself. For this purpose, a new client-type, the COPS-MAID client type, is defined in the following sections. This client-type is used to transport admission control messages despite of the signalling protocol (e.g. RSVP, SIP, H.323) and of the QoS/TE architecture (e.g. DiffServ/MPLS). Therefore a single client could be supported by the PDP shifting the complexity on the border router where appropriate Inter Working Units (IWUs) are used to map protocol specific messages into generalized client messages. Carrozzo, et al. Expires - Aprily 2004 [Page 4] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 In order to provide a correct policy decision and perform admission control, the BB MUST know the following information: - Traffic origin: > host which originated the flow; > BR interface where the traffic will pass through; - Traffic direction: > egress BR for the flow; > core routers the flow will go across (got from a Path Computation System); - Traffic type: > traffic characterization; > QoS parameters; - Temporal information (optional) > start time, end time, repetition intervals; Besides of the specific signalling protocol used by the clients, a subset of these information MUST be passed from the PEP to the PDP by means of the COPS-MAID client type, while the remaining ones will be somehow learned by the BB (e.g. via SNMP). 2. COPS-MAID extensions The meaning and usage of several COPS objects is affected when used with the COPS-MAID client type. This section describes these objects and their usage. 2.1 Client Type COPS-MAID is COPS client-type TBD. 2.2 Context Object The semantics of the Context object for COPS-MAID is as follows: - R-Type (Request Type Flag) > R-Type = 0x01: Incoming-Message/Admission Control Requests; > R-Type = 0x02: Resource Allocation Request; > R-Type = 0x08: Configuration request; For the COPS-MAID client-type the R-Type flag 0x04 (Outgoing-Message Request) is not used. - M-Type (Message Type) > M-Type = 0x01: Add request; > M-Type = 0x02: Release request; > M-Type = 0x03: Modify request; Carrozzo, et al. Expires - Aprily 2004 [Page 5] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 2.3 COPS-MAID Protocol Objects Format All the objects described in this section have to be intended as objects/attributes encapsulated within other "higher level" COPS objects. In particular, they are carried in the COPS-MAID Client Specific Information Object (ref. 3.1) for the PEP -> PDP communication, and in the Client Specific Decision Object (ref. 3.2) for the PDP -> PEP direction. These COPS-MAID objects have a TLV format (Type-Length-Value) where Type (16 bit) identifies univocally the object, Length (16 bit) indicates the length of the object in Bytes (including the header) and Value is the content of the object. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.4 Request ID Object This object is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP, or in the Client Specific Decision data sent from a PDP to a PEP. It allows to bind requests sent by the PEP and having the same COPS Handle Object with responses coming from the PDP (see [4]). This mechanism allows an COPS-MAID PEP to make more than one request for a specific state (identified by the Handle Object) before receiving a PDP response. The Request ID Object is chosen by the PEP and it is opaque to the PDP. For each request a different Request ID is chosen by the PEP. Request ID values can be reused if they are associated to different Handle Objects. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In case of PCS enabled on BB, the Request ID / source MA-BR address pair provides a unique identifier for the path computation which returns an ERO for the RSVP-TE signalling. Carrozzo, et al. Expires - Aprily 2004 [Page 6] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 2.5 Source Host IPv4 address Object This object specifies the IPv4 address of the host originating the flow for which a PDP decision is requested. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. The host IP address could be useful to the Bandwidth Broker in order to perform Authorization operations. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Host IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.6 Destination IPv4 address Object This object specifies the IPv4 address of the host which is the destination of the flow that requires a PDP decision. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. The destination address is needed each time the BR is not aware of the egress router for the traffic flow for which is performing the request. Moreover, the destination address could be useful to the Bandwidth Broker in order to perform flow authorization operations. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Host IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.7 Source Host IPv6 address Object This object specifies the IPv6 address of the host originating the flow for which a PDP decision is requested. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Carrozzo, et al. Expires - Aprily 2004 [Page 7] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 | Source Host IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.8 Destination IPv6 address Object This object specifies the IPv6 address of the host, which is the destination of the flow that requires a PDP decision. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. The destination address is needed each time the BR is not aware of the egress router for the traffic flow for which is performing the request. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination Host IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.9 IPv4 Ingress Border Router Interface Object/TrunkID This object specifies the IPv4 address of the ingress border router output interface for the traffic flow which requires resource allocation. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress BR Output IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Label Type field is used to specify the semantics of the following label object: Carrozzo, et al. Expires - Aprily 2004 [Page 8] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 - Label Type = 0x00000001: DiffServ; - Label Type = 0x00000002: MPLS; - Label Type = 0x00000003: ATM; - Label Type = TBA; The Label object specifies an identifier for the traffic flow with respect to the specified semantic type (e.g. a DSCP in case of DiffServ semantics, a label in case of MPLS, etc.). The couple IPv4 output address/label identifies univocally the trunk where the traffic flow has to be aggregated. 2.10 IPv6 Ingress Border Router Interface Object/TrunkID This object specifies the IPv6 address of the ingress border router output interface for the traffic flow which requires resource allocation. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Ingress BR Output IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Label Type field is used to specify the semantics of the label: - Label Type = 0x00000001: DiffServ; - Label Type = 0x00000002: MPLS; - Label Type = 0x00000003: ATM; - Label Type = TBA The Label value is set according to the specified Label Type. 2.11 Egress Border Router Interface Object This object specifies the IPv4 Egress Border Router interface address for the traffic flow for which the resource allocation request is performed. It is carried in the Client Specific Information Object of Carrozzo, et al. Expires - Aprily 2004 [Page 9] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress BR Input IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.12 IPv6 Egress Border Router Interface Object This object specifies the IPv6 Egress Border Router interface address for the traffic flow for which the resource allocation request is performed. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Egress BR Input IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.13 Traffic Type Object Traffic Type IDs are maintained in the form of a list where each Traffic Type ID value corresponds to a predefined (either standardized or client defined) characterization: Traffic Type ID = value -> characterization. - Traffic Type ID = TBA - Traffic Type ID = TBA Traffic Type Object and Traffic Characterization Object, described in the next paragraph, can be used together or separately, allowing to specify traffic parameters at different levels. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Type ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Carrozzo, et al. Expires - Aprily 2004 [Page 10] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 2.14 Traffic Characterization Object The traffic characterization object describes the traffic characterization parameters for the traffic flow. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 | Length = var | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclude-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-all | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | MPLS/DS TSpec number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS/DS Tspec sub-objects | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource affinities are declared by three 32 bit masks: - Exclude-any (32-bit), for the set of attribute filters associated with a tunnel any of which renders a link unacceptable; - Include-any (32-bit), for the set of attribute filters associated with a tunnel any of which renders a link acceptable) - Include-all (32-bit), for the set of attribute filters associated with a tunnel all of which must be present for a link to be acceptable. Priorities for the flow is specified by: - Setup Priority (in the range of 0 to 7), which specifies priority of the session with respect to taking resources; - Holding Priority (in the range of 0 to 7), which specifies priority of the session with respect to holding resources; The MPLS/DS TSpec number specifies the total number of MPLS/DS Traffic Specification entries (sub-objects) contained in the object. Each sub-object is structured as follows: 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | DS Behaviour Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Profile Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Carrozzo, et al. Expires - Aprily 2004 [Page 11] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 | Profile Characterization | | ... | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Types for MPLS/DS Tspec sub-object are: - Type = 0x0001: E-LSP Tspec; - Type = 0x0002: L-LSP Tspec; and depending on Type value the DS Behaviour Class field contains the EXP value (3 bit û left aligned) or the PHBID field (16 bit, ref. [5]). 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | EXP | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | PHBID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | The Traffic Profile Type value specifies the type of characterization attached to the object. The following characterization type are supported: - Traffic Profile Type 1 = 0x00000001: Average & Peak Rate (r, p, m, M); - Traffic Profile Type 2 = 0x00000002: LBAP point (r, b, p, m, M, avgr); - Traffic Profile Type 3 = 0x00000003: 3D LBAP point (l, r, b, p, M, avgr); - Traffic Profile Type 4 = 0x00000004: LBAP plot (p, m, M, avgr, (r, b), ... , (r, b)); - Traffic Profile Type 5 = 0x00000005: 3D-LBAP plot (p, m, M, avgr, (l, (r,b) plot,..., l, (r,b)plot)); where r indicates the rate (bytes/s), b the bucket size (bytes), p the peak rate (bytes/s), m the minimum policed unit (bytes), M the connection MTU (bytes), avgr the average rate (bytes/sec) and l the loss probability. Carrozzo, et al. Expires - Aprily 2004 [Page 12] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 2.14.1 Profile Characterization for Type 1 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum policed unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.14.2 Profile Characterization for Type 2 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bucket Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum policed unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.14.3 Profile Characterization for Type 3 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss Probability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bucket Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum policed unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Carrozzo, et al. Expires - Aprily 2004 [Page 13] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 2.14.4 Profile Characterization for Type 4 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum policed unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bucket Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bucket Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.14.5 Profile Characterization for Type 5 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum policed unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss Probability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bucket Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bucket Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Carrozzo, et al. Expires - Aprily 2004 [Page 14] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 | Loss Probability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bucket Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bucket Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.15 QoS Class Description Object This object specifies the QoS class to which the traffic flow belongs to. Four different QoS classes are defined: - Class Type = 0x00000001: bounded losses; - Class Type = 0x00000002: guaranteed bandwidth; - Class Type = 0x00000003: guaranteed bandwidth + bounded delay; - Class Type = 0x00000004: guaranteed bandwidth + bounded delay + bounded jitter. Each one of this classes has more stringent QoS guarantees than the previous class. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Class Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.16 QoS Parameters Description Object This object defines the QoS parameters requested. Four different parameters are defined: - bandwidth; - delay; - jitter; - loss probability; For each of the previous parameters a slack term could be indicated: while the bandwidth slack term must be subtracted to the bandwidth parameter in order to find the minimum allowed bandwidth, the jitter Carrozzo, et al. Expires - Aprily 2004 [Page 15] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 and delay slack terms must be added to the respective parameters in order to find the maximum allowed delay and jitter. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 13 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth (bytes/sec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Slack term | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Jitter (msec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Jitter Slack term | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay (msec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay Slack term | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.17 LSP Recovery description Object This object is used by the PEP to request by the way of a PDP a Path Computation System (PCS) to compute a pair of Explicit Route objects for a traffic flow. It is carried in the Client Specific Resource Allocation Request data Object of a Decision Message sent from a PDP to a PEP. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 14 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recovery type | Recovery diversity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Values defined for recovery type are: - Recovery type = 0x0000: Unprotected - Recovery type = 0x0001: Path Protection - Recovery type = 0x0002: Link Protection - Recovery type = 0x0003: Path Fast-Restoration (with preplanning of a backup ERO) - Recovery type = 0x0004: Link Fast-Restoration (with preplanning of a partial detour for each link) - Recovery type = TBA Values defined for recovery diversity are: - Recovery diversity = 0x0000: None - Recovery diversity = 0x0001: Node - Recovery diversity = 0x0002: Link Carrozzo, et al. Expires - Aprily 2004 [Page 16] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 - Recovery diversity = 0x0003: SRLG - Recovery diversity = TBA 2.18 COPS-MAID Decision Object This object is used by the PDP to inform the PEP how to aggregate the flow. It is carried in the Client Specific Decision Data Object of a Decision Message sent from a PDP to a PEP. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 15 | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Label Type field is used to specify the semantics of the label: - Label Type = 0x00000001: DiffServ; - Label Type = 0x00000002: MPLS; - Label Type = 0x00000003: ATM; - Label Type = TBA; The Label value is set according to the specified Label Type. 2.19 Temporal information object The temporal information object is used to specify the time interval inside which the request is valid. It is carried in the Client Specific Information Object of a Request Message sent from a PEP to a PDP or in the Client Specific Decision data sent from a PDP to a PEP. y means of this object one or more time intervals and/or periodically repeated time intervals could be defined. An ASCII string is used to describe the temporal information. If the string length is not multiple of 32 bits appropriate zero padding bytes are used. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =16 | Length = var | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCII String | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Carrozzo, et al. Expires - Aprily 2004 [Page 17] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 The ASCII string is in the form: {[ ] [ ] ... [ ] } where: - start date and end date are in the format: "ddmmyyyy"; - start day of the week and end day of the week are expressed by one of the following character: A-B-C-D-E-F-G. The letters are the coding for: sun - mon - tue - wen - thu - fri - sat , respectively; - start hour and end hour are in the format: "hhmm". Blanks, present in the string above, are used for increase the readability, and are suppressed in the TempInfo object value. The ASCII string starts with "{" and ends with "}". Each time interval is specified internally to the characters "[" and "]". This time interval is the intersection of the time intervals (separated by the character "-") specified internally to the characters "<" and ">". Otherwise the global time interval is the union of all the time intervals specified internally to the characters "[" and "]". The character ("*") is used as wildcard. As an example, the ASCII string {[<15092001-15122001><1600-1800>] [<01042002-30062002><*><1700-1900>]} means: every Monday, Wednesday and Friday between September the 15th and December the 15th 2001, from 16:00 to 18:00 and everyday between April the 1st and June the 30th 2002, from 17:00 to 19:00. This string could be, e.g , used to perform a resource allocation request for a tele-teaching scenario. 2.20 Explicit Route object The contents of an Explicit Route object are a series of variable- length data items called sub-bjects. An explicit route is a particular path in the network topology. An explicit route is described as a list of groups of nodes along the explicit route. In addition to the ability to identify specific nodes along the path, an explicit route can identify a group of nodes (called abstract node) Carrozzo, et al. Expires - Aprily 2004 [Page 18] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 that must be traversed along the path. This capability allows the routing system a significant amount of local flexibility in fulfilling a request for an explicit route. This capability allows the generator of the explicit route to have imperfect information about the details of the path. The explicit route is encoded as a series of sub-objects contained in an ERO object. Each sub-object identifies a group of nodes in the explicit route. An explicit route is thus a specification of groups of nodes to be traversed. This object is used by the PDP to inform the MA-BR signalling protocol for the core network how to setup an LSP. It is carried in the Client Specific Decision Data Object of a Decision Message sent from a PDP to a PEP. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 17 | Length = var | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | Sub-objects | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.20.1 ERO Sub-objects Each sub-object has the form: 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length = var | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | | Sub-object contents | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The L bit is an attribute of the sub-object. The L bit is set if the sub-object represents a loose hop in the explicit route. If the bit is not set, the sub-object represents a strict hop in the explicit route. The path between a strict node and its preceding node MUST include only network nodes from the strict node and its preceding abstract node. The path between a loose node and its preceding node MAY include other network nodes that are not part of the strict node or its preceding abstract node. The Type indicates the type of contents of the sub-object. Currently defined values are: - Type = 0x01: IPv4 prefix - Type = 0x02: IPv6 prefix - Type = 0x20: Autonomous system number Carrozzo, et al. Expires - Aprily 2004 [Page 19] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 The Length contains the total length of the sub-object in bytes, including the L, Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4. 2.20.1.1 Sub-object 1: IPv4 prefix 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type = 0x01 | Length = 8 | Ingress i/f IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress i/f IPv4 addr (contd) | Prefix length | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Ingress interface IPv4 address (32) is treated as a prefix based on the prefix length (8 bit) value below. Bits beyond the prefix are ignored on receipt and SHOULD be set to zero on transmission. Note that a prefix length of 32 indicates a single IPv4 node. 2.20.1.2 Sub-object 1: IPv6 prefix 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type = 0x02 | Length = 20 | Ingress i/f IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress i/f IPv6 addr (contd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress i/f IPv6 addr (contd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress i/f IPv6 addr (contd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress i/f IPv4 addr (contd) | Prefix length | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Ingress interface IPv6 address (128) is treated as a prefix based on the prefix length (8 bit) value below. Bits beyond the prefix are ignored on receipt and SHOULD be set to zero on transmission. Note that a prefix length of 128 indicates a single IPv6 node. 2.20.1.3 Sub-object 32: Autonomous System Number The contents of an Autonomous System (AS) number sub-object are a 4- octet AS number. The abstract node represented by this sub-object is the set of nodes belonging to the autonomous system. 0 7 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type = 0x20 | Length = 8 | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Carrozzo, et al. Expires - Aprily 2004 [Page 20] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 2.21 Reject Reason Object This object specifies the reason of a negative answer coming from the PDP. It is carried in the Client Specific Decision Data Object of a Decision Message sent from a PDP to a PEP. Reason Code: - Reason Code = 0x00000001: Resource unavailable; - Reason Code = 0x00000002: Unsupported Traffic Type; - Reason Code = 0x00000003: Unacceptable Src Address; - Reason Code = 0x00000004: Unacceptable Dst Address; - Reason Code = 0x00000005: Invalid Traffic Parameters; - Reason Code = 0x00000006: No primary route to host; - Reason Code = 0x00000007: No backup route to host; - Reason Code = 0x00000008: No diversity for backup route; - Reason Code = .... 3. COPS-MAID Client Specific Information Object 3.1 COPS-MAID Client Specific RAR data The COPS-MAID Client Specific Resource Allocation Request data (RAR) is carried in the REQ messages for the COPS-MAID client and contains the description of the resources and has a different format depending on whether the type of request is Add/Release or Modify. For Add and Release messages the COPS-MAID ClientSI RAR is: ::= [] [] [] [] [] [] [] [] [] [] [] [] [] [] with: X(s) ::= | whether for the Modify messages is: Carrozzo, et al. Expires - Aprily 2004 [Page 21] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 ::= [] (new) [] (old) [](new) [] (old) [](new) [](old) [](new) [](old) [](new) [](old) [] (new) [] (old) [] (new) [] (old) [] (new) [] (old) [] (new) [] (old) [] (new) [] (old) [] (new) [] (old) [] (new) [] (old) 3.2 COPS-MAID Client Specific Decision data The COPS-MAID ClientSI Decision data is carried in the COPS decision message and contains the PDP decision for a certain Request ID. ::= < COPS-MAIDDec> | < RejRea> [] [] [] [] [] [] [] [] [] [] [] [] - primary [] û backup Carrozzo, et al. Expires - Aprily 2004 [Page 22] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 4. Message content 4.1 Request Message (REQ) PEP -> PDP ::= [] [] [] [] 4.2 Decision Message (DEC) PDP -> PEP ::= | [] ::= 4.3 Report State Message (RPT) PEP -> PDP The RPT Message is sent by the PEP to PDP in case of problems with a received Decision Message. RPT Message has the following format: ::= [] ::= Security Considerations The extensions proposed in this document do not raise any new security concerns with respect to those declared in [3]. Carrozzo, et al. Expires - Aprily 2004 [Page 23] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, "The COPS (Common Open Policy Service) Protocol", IETF RFC 2748, January 2000 4 S. Herzdog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry, "COPS Usage for RSVP", IETF RFC 2749, January 2000 5 D.Black, S. Brim, B. Carpenter, F. Le Faucheur, ôPer Hop Behavior Identification Codeö, RFC 3140, June 2001 Acknowledgments The authors would like to thank G. Giorgi and F. Mustacchio for their comments on this draft. Author's Addresses Gino Carrozzo META Centre - Consorzio Pisa Ricerche c.so Italia, 116 56125 Pisa, ITALY Email: g.carrozzo@cpr.it Nicola Ciulli META Centre - Consorzio Pisa Ricerche c.so Italia, 116 56125 Pisa, ITALY Email: n.ciulli@cpr.it Giacomo Sergio META Centre - Consorzio Pisa Ricerche c.so Italia, 116 56125 Pisa, ITALY Email: g.sergio@cpr.it Carrozzo, et al. Expires - Aprily 2004 [Page 24] Internet Draft draft-cpr-rap-cops-maid-00.txt November 2003 Intellectual Property Rights Notices 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 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 implementers 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. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and 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. Carrozzo, et al. Expires - Aprily 2004 [Page 25]