< draft-huang-dime-pcn-collection-01.txt   draft-huang-dime-pcn-collection-02.txt >
Network Working Group F. Huang Network Working Group F. Huang
Internet-Draft T. Taylor Internet-Draft T. Taylor
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: January 13, 2010 G. Zorn, Ed. Expires: April 29, 2010 G. Zorn, Ed.
Network Zen Network Zen
July 12, 2009 H. Tschofenig
Nokia Siemens Networks
October 26, 2009
The Diameter Precongestion Notification (PCN) Data Collection The Diameter Precongestion Notification (PCN) Data Collection
Application Application
draft-huang-dime-pcn-collection-01 draft-huang-dime-pcn-collection-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
Pre-Congestion notification (PCN) is a technique for maintaining QoS Pre-Congestion notification (PCN) is a technique for maintaining QoS
for inelastic flows in a DIFFServ domain. The PCN architecture for inelastic flows in a DIFFServ domain. The PCN architecture
requires that egress nodes send reports of congestion-related events requires that egress nodes send reports of congestion-related events
(flow admission state change, excess flow) reliably to a policy reliably to a policy decision point. The policy decision point might
decision point. The ITU-T is working on a variant of this be located in different places of the network. In one architectural
architecture which places the policy decision point in a central node variant the policy decision point is a central node rather than co-
rather than ingress or egress nodes of the network. In this case the located with the ingress or the egress nodes of the network. In this
policy decision point must request and obtain certain data from an case it needs to have access to certain information from the edge
ingress node when it receives an excess flow report affecting that nodes. This memo defines a Diameter application to support the
ingress node. This memo defines a Diameter application to support ingress and the egress node to interact with the Diameter server
egress node reporting and data collection from the ingress node. The acting as a policy decision point.
nature of the data flows requires the policy decision point to act
both as server and as client. Hence this memo draws upon the
precedent established by the Rw application (RFC 5431 and ITU-T
Recommendation Q.3303.3).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Diameter PCN Data Collection Application . . . . . . . . . 5 3.1. Overall Procedures . . . . . . . . . . . . . . . . . . . . 5
4.1. Advertising Application Support . . . . . . . . . . . . . 5 3.2. Egress Node behavior . . . . . . . . . . . . . . . . . . . 5
4.2. Diameter Session Usage . . . . . . . . . . . . . . . . . . 5 3.3. PDP behavior . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Ingress Node behavior . . . . . . . . . . . . . . . . . . 6
4.3.1. Congestion-Report-Request (CRR) Command . . . . . . . 6 4. Diameter PCN Data Collection Application . . . . . . . . . . . 6
4.3.2. Congestion-Report-Answer (CRA) Command . . . . . . . . 6 4.1. Advertising Application Support . . . . . . . . . . . . . 6
4.3.3. Measurement-Poll-Request (MPR) Command . . . . . . . . 7 4.2. Session Management . . . . . . . . . . . . . . . . . . . . 6
4.3.4. Measurement-Poll-Answer (MPA) Command . . . . . . . . 8 4.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Attribute Value Pairs (AVPs) . . . . . . . . . . . . . . . 8 4.3.1. Congestion-Report-Request (CRR) Command . . . . . . . 7
4.4.1. I-E-Aggregate-Id AVP . . . . . . . . . . . . . . . . . 8 4.3.2. Congestion-Report-Answer (CRA) Command . . . . . . . . 8
4.4.2. PCN-Congestion-Info AVP . . . . . . . . . . . . . . . 8 4.3.3. Measurement-Poll-Request (MPR) Command . . . . . . . . 8
4.4.3. CLE-Value AVP . . . . . . . . . . . . . . . . . . . . 9 4.3.4. Measurement-Poll-Answer (MPA) Command . . . . . . . . 9
4.4.4. CLE-Report-Reason AVP . . . . . . . . . . . . . . . . 9 4.4. Attribute Value Pairs (AVPs) . . . . . . . . . . . . . . . 9
4.4.5. PCN-Excess-Flow-Info AVP . . . . . . . . . . . . . . . 9 4.4.1. I-E-Aggregate-Id AVP . . . . . . . . . . . . . . . . . 9
4.4.6. I-E-Aggregate-Excess-Rate AVP . . . . . . . . . . . . 10 4.4.2. PCN-Ingress-Node-Address AVP . . . . . . . . . . . . . 10
4.4.7. Flow-Number AVP . . . . . . . . . . . . . . . . . . . 10 4.4.3. PCN-Egress-Node-Address AVP . . . . . . . . . . . . . 10
4.4.8. Flow-Description AVP . . . . . . . . . . . . . . . . . 10 4.4.4. Framed-IP-Address AVP . . . . . . . . . . . . . . . . 10
4.4.9. PCN-Sent-Info AVP . . . . . . . . . . . . . . . . . . 10 4.4.5. Framed-IPv6-prefix AVP . . . . . . . . . . . . . . . . 10
4.4.10. I-E-Aggregate-Sent-Rate AVP . . . . . . . . . . . . . 11 4.4.6. VLAN-ID-Range AVP . . . . . . . . . . . . . . . . . . 10
4.5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.7. PCN-Congestion-Info AVP . . . . . . . . . . . . . . . 11
4.5.1. Overall Procedures . . . . . . . . . . . . . . . . . . 11 4.4.8. CLE-Value AVP . . . . . . . . . . . . . . . . . . . . 11
4.5.2. Egress Node behavior . . . . . . . . . . . . . . . . . 11 4.4.9. CLE-Report-Reason AVP . . . . . . . . . . . . . . . . 11
4.5.3. PDP behavior . . . . . . . . . . . . . . . . . . . . . 12 4.4.10. PCN-Excess-Flow-Info AVP . . . . . . . . . . . . . . . 11
4.5.4. Ingress Node behavior . . . . . . . . . . . . . . . . 12 4.4.11. I-E-Aggregate-Excess-Rate AVP . . . . . . . . . . . . 12
4.4.12. Classifier AVP . . . . . . . . . . . . . . . . . . . . 12
4.4.13. PCN-Sent-Info AVP . . . . . . . . . . . . . . . . . . 12
4.4.14. I-E-Aggregate-Sent-Rate AVP . . . . . . . . . . . . . 12
4.5. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. Diameter Application Identifier . . . . . . . . . . . . . 13 5.1. Diameter Application Identifier . . . . . . . . . . . . . 13
5.2. Diameter Command Codes . . . . . . . . . . . . . . . . . . 13 5.2. Diameter Command Codes . . . . . . . . . . . . . . . . . . 14
5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 13 5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Traffic Security . . . . . . . . . . . . . . . . . . . . . 14 6.1. Traffic Security . . . . . . . . . . . . . . . . . . . . . 15
6.2. Device Security . . . . . . . . . . . . . . . . . . . . . 14 6.2. Device Security . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Related Work in ITU-T . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The objective of Pre-Congestion Notification (PCN) is to protect the The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain quality of service (QoS) of inelastic flows within a Diffserv domain
[RFC2475] in a simple, scalable and robust fashion. Two mechanisms [RFC2475] in a simple, scalable and robust fashion. Admission
are used: admission control, to decide whether to admit or block a control allows to decide whether to admit or reject a new flow
new flow request, and (in abnormal circumstances) flow termination to request, and (in abnormal circumstances, such as router failure) to
decide whether to terminate some of the existing flows. Together provide flow termination of already admitted flows. These two
they protect the QoS of previously admitted flows. To achieve this, mechanisms together aim to protect the QoS properties of previously
the overall rate of the PCN-traffic is metered on every link in the admitted flows. To achieve this, the overall rate of the PCN traffic
PCN-domain, and PCN-packets are appropriately marked when certain is metered on every link in the PCN domain, and PCN packets are
configured rates are exceeded. These configured rates are below the appropriately marked when certain configured rates are exceeded.
rate of the link thus providing notification before any congestion These configured rates are below the rate of the link thus providing
occurs ("pre-congestion notification"). The level of marking allows notification before any congestion occurs ("pre-congestion
decisions to be made about whether to admit or terminate. For a full notification"). The level of marking allows decisions to be made
description of the PCN architecture, see [RFC5559]. about whether to admit or terminate. A more detailed description of
the architecture can be found in [RFC5559].
Marking statistics are gathered by egress nodes on a per-ingress- Marking statistics are gathered by egress nodes on a per-ingress-
egress aggregate basis. They are processed to determine whether new egress aggregate basis. They are processed to determine whether new
flows can be admitted to the aggregate over the next measurement flows can be admitted to the aggregate over the next measurement
interval and whether some flows should be terminated to protect QoS interval and whether some flows should be terminated to protect QoS
for the remainder (flow termination is expected to be relatively for the remainder (flow termination is expected to be relatively
infrequent, typically a result of network failure). The admission infrequent, typically a result of network failure). The admission
state is based on a congestion level estimate (CLE), which the egress state is based on a congestion level estimate (CLE), which the egress
node reports to a decision point whenever the CLE value passes a set node reports to a decision point whenever the CLE value passes a set
threshold (upward or downward). The decision to terminate flows is threshold (upward or downward). The decision to terminate flows is
made on the basis of a different criterion. When the egress node made on the basis of a different criterion. When the egress node
detects that this criterion has been satisfied, it sends a report to detects that this criterion has been satisfied, it sends a report to
the decision node providing measurement values that are used to the decision node providing measurement values that are used to
determine the total volume of traffic that must be terminated. If determine the total volume of traffic that must be terminated. If
equal cost multipath (ECMP) routing is in use, it also sends a list equal cost multipath (ECMP) routing is in use, it also sends a list
of individual flows that were marked at the termination level. of individual flows that were marked at the termination level.
2. Related Work 2. Requirements Language
The ITU-T is doing work to exploit the PCN technology in an The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
environment where the decisions are made by a central policy decision "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
point (PDP) [Q.3303.3], which needs the information generated by PCN document are to be interpreted as described in RFC 2119 [RFC2119].
marking to support per-flow decisions on admission and termination.
This memo defines a Diameter application to transfer the information
from edge nodes to the PDP. Egress node reports are sent by the
egress node acting as client to the PDP acting as server. Data
generated at the ingress node are needed only when flow termination
is required. They are requested by the PDP acting as client and sent
in responses by the ingress node acting as server. The PDP thus acts
both as client and as server in the same application. The Rw
application [RFC5431] provides a precedent for such an application.
The PCN Data Collection application is related to existing ITU-T 3. Procedures
applications as follows:
o The Rs application allows application-level functions to request The following subsections discuss the processing requirements placed
flow admission for individual application flows. upon the various participating Diameter nodes by the PCN Data
Collection application.
o The Rw application provides the control linkage between a Policy 3.1. Overall Procedures
Decision Point and an ingress router, to pass down decisions on
flow admission following either the push or the pull model. The
Rw application also passes flow termination decisions.
As can be seen from this brief description, the PCN Data Collection The egress node measures the traffic from a particular ingress node,
application defined in this memo is complementary to the Rw and calculates the congestion level estimate(CLE) at the ingress-
application. Within the strict terms of the ITU-T architecture, it egress aggregate level. The egress node may compare the CLE
is a realization of a different interface, the Rc interface. calculated at the current interval with the CLE calculated at the
However, the PCN Data Collection application is intended for use in last interval, if the difference of the two CLEs exceeds a preset
any of a number of architectures based on a centralized policy range, the egress node sends the feedback information, including at
decision element. least the current CLE, to the PDP. After receiving the feedback
information, the PDP saves the it for admission control and flow
termination. After receiving a service flow request, the PDP can
determine whether to admit the request or not based on the feedback
information. Besides, the PDP also decides whether some of the
admitted flows need to be terminated. The PDP needs to signal to the
ingress node the decision about admission or termination.
3. Requirements Language 3.2. Egress Node behavior
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", For each ingress-egress aggregate flow it serves, the egress node
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this meters received traffic for PCN markings, recomputes its smoothed
document are to be interpreted as described in RFC 2119 [RFC2119]. congestion level estimate, and determines whether there is excess
flow in successive measurement periods in accordance with the PCN
edge behavior specification (e.g. ietf-pcn-cl-edge-behaviour
[I-D.ietf-pcn-cl-edge-behaviour], ietf-pcn-sm-edge-behaviour
[I-D.ietf-pcn-sm-edge-behaviour]) deployed in the domain. When a
change in the smoothed congestion level estimate causes it to cross a
reporting threshold, either upward or downward, the egress node MUST
send a Congestion-Report-Request message to the PDP. Similarly, the
egress node MUST send a Congestion-Report-Request message to the PDP
when excess flow is detected for an ingress-egress aggregate served
by that node.
4. The Diameter PCN Data Collection Application The Event-Timestamp AVP MUST be present, and MUST provide the ending
time of the measurement period from which the data triggering the
generation of the message were derived. At least one instance either
of the PCN-Congestion-Info or the PCN-Excess-Flow-Info AVP MUST be
present. Both AVPs MAY be present for the same ingress-egress
aggregate, if both apply according to the edge behavior
specification. Multiple instances of either AVP MAY be present, but
each instance MUST report on a different ingress-egress aggregate.
3.3. PDP behavior
If the PDP receives an Congestion-Report-Request (CRR) identified as
belonging to the PCN Data Collection application, it MUST acknowledge
the message with an Congestion-Report-Answer (CRA). The PDP usage of
the information provided by PCN-Congestion-Info and PCN-Excess-Flow-
Info AVPs is described in the applicable edge behavior specification.
When the PDP receives an CRR containing a PCN-Excess-Flow-Info AVP,
it MAY send a Measurement-Poll-Request (MPR) to the ingress node for
the aggregate concerned. The PDP will make the decision about
sending the MPR depending on the content of the received report. In
case the report indicates that a critical threshold has been reached
then it has to obtain information about which and how many flows to
terminate. The I-E-Aggregate-Id MUST identify the ingress-egress
aggregate flow for which information is being requested. The Event-
Timestamp MUST be present if it was present in the CRR that contained
the PCN-Excess-Flow-Info AVP, and MUST have the same value.
If the PDP receives a successful Measurement-Poll-Answer message, it
uses the information contained in the PCN-Sent-Info AVP as described
in the applicable edge behavior specification.
3.4. Ingress Node behavior
When an ingress node receives an MPR, it MUST generate a Measurement-
Poll-Answer message containing an instance of the PCN-Sent-Info AVP.
The I-E-Aggregate-Id within the PCN-Sent-Info AVP MUST be the same as
received in the MPR, and the I-E-Aggregate-Sent-Rate MUST be a rate
measured for that aggregate. If Event-Timestamp is present in the
MPR, the measurement upon which I-E-Aggregate-Sent-Rate is based
SHOULD be that for the latest measurement period ending before or at
the time given by Event-Timestamp, if available. In any case, Event-
Timestamp MUST be present in the MPA, and if it is, MUST give the
end-time of the measurement period upon which I-E-Aggregate-Sent-Rate
is based.
4. Diameter PCN Data Collection Application
4.1. Advertising Application Support 4.1. Advertising Application Support
Clients, servers, and proxies supporting the PCN Data Collection Clients, servers, and proxies supporting the PCN Data Collection
application MUST advertise support by including the value <AID> in application MUST advertise support by including the value <AID> in
the Auth-Application-Id of Congestion-Report-Request (CRR), the Auth-Application-Id of Congestion-Report-Request (CRR),
Congestion-Report-Answer (CRA), Measurement-Poll-Request (MPR), and Congestion-Report-Answer (CRA), Measurement-Poll-Request (MPR), and
Measurement-Poll-Answer (MPA) messages. Measurement-Poll-Answer (MPA) messages.
4.2. Diameter Session Usage 4.2. Session Management
Diameter sessions are implicitly terminated. An implicitly Diameter sessions are implicitly terminated. An implicitly
terminated session is one for which the server does not maintain terminated session is one for which the server does not maintain
state information. The client does not need to send any re- session state information. The client does not need to send any re-
authorization or session termination requests to the server. The authorization or session termination requests to the server. The
Diameter base protocol includes the Auth-Session-State AVP as the Diameter base protocol includes the Auth-Session-State AVP as the
mechanism for the implementation of implicitly terminated sessions. mechanism for the implementation of implicitly terminated sessions.
The client (server) SHALL include in its requests (responses) the The client (server) SHALL include in its requests (responses) the
Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as
described in RFC 3588 [RFC3588]. As a consequence, the server does described in RFC 3588 [RFC3588]. As a consequence, the server does
not maintain any state information about this session and the client not maintain any state information about this session and the client
does not need to send any session termination request. Neither the does not need to send any session termination request. Neither the
Authorization-Lifetime AVP nor the Session-Timeout AVP SHALL be Authorization-Lifetime AVP nor the Session-Timeout AVP SHALL be
present in requests or responses. present in requests or responses.
4.3. Commands 4.3. Commands
skipping to change at page 6, line 23 skipping to change at page 7, line 27
Measurement-Poll-Request (MPR) and Measurement-Poll-Answer (MPA). Measurement-Poll-Request (MPR) and Measurement-Poll-Answer (MPA).
4.3.1. Congestion-Report-Request (CRR) Command 4.3.1. Congestion-Report-Request (CRR) Command
The egress node sends the Congestion-Report-Request (CRR) command, The egress node sends the Congestion-Report-Request (CRR) command,
indicated by the Command-Code field set to <CC1> and the Command indicated by the Command-Code field set to <CC1> and the Command
Flags' 'R' bit set, to report when the congestion level estimate Flags' 'R' bit set, to report when the congestion level estimate
(CLE) moves above or drops below the pre-congestion reporting (CLE) moves above or drops below the pre-congestion reporting
threshold, or when an excess flow condition is detected. Multiple threshold, or when an excess flow condition is detected. Multiple
reports MAY be included in the same message, as described in reports MAY be included in the same message, as described in
Section 4.5.2. Section 3.2.
Message format: Message format:
<CRR> ::= < Diameter Header: CC1, REQ, PXY > <CRR> ::= < Diameter Header: CC1, REQ, PXY >
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Auth-Application-Id }
{ Auth-Session-State } { Auth-Session-State }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
skipping to change at page 6, line 45 skipping to change at page 7, line 49
[ Event-Timestamp ] [ Event-Timestamp ]
* [ PCN-Congestion-Info ] * [ PCN-Congestion-Info ]
* [ PCN-Excess-Flow-Info ] * [ PCN-Excess-Flow-Info ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ AVP ] * [ AVP ]
At least one instance of the PCN-Congestion-Info or the PCN-Excess- At least one instance of the PCN-Congestion-Info or the PCN-Excess-
Flow-Info AVP MUST be present; the value of the Session-Id AVP MUST Flow-Info AVP MUST be present; the value of the Session-Id AVP MUST
be unique and SHOULD be set according to the recommendations in be unique and SHOULD be set according to the recommendations in
Section 8.8 of RFC 3588. Section 8.8 of RFC 3588 [RFC3588].
4.3.2. Congestion-Report-Answer (CRA) Command 4.3.2. Congestion-Report-Answer (CRA) Command
The PDP uses the Congestion-Report-Answer (CRA) command, indicated by The PDP uses the Congestion-Report-Answer (CRA) command, indicated by
the Command-Code field set to <CC2> and the Command Flags' 'R' bit the Command-Code field set to <CC2> and the Command Flags' 'R' bit
cleared, to acknowledge an Congestion-Report-Request command sent by cleared, to acknowledge an Congestion-Report-Request command sent by
an egress node. The Congestion-Report-Answer command contains the an egress node. The Congestion-Report-Answer command contains the
same Session-Id as the corresponding request. same Session-Id as the corresponding request.
Message format: Message format:
skipping to change at page 7, line 30 skipping to change at page 8, line 36
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
4.3.3. Measurement-Poll-Request (MPR) Command 4.3.3. Measurement-Poll-Request (MPR) Command
The PDP sends the Measurement-Poll-Request (MPR) command, indicated The PDP sends the Measurement-Poll-Request (MPR) command, indicated
by the Command-Code field set to <CC3> and the Command Flags' 'R' bit by the Command-Code field set to <CC3> and the Command Flags' 'R' bit
set, to request that an ingress node report the rate at which PCN- set, to request that an ingress node report the rate at which PCN-
marked traffic has been forwarded to a given ingress-egress marked traffic has been forwarded to a given ingress-egress
aggregate, measured over a given measurement period as described in aggregate, measured over a given measurement period as described in
Section 4.5.4. The value of the Session-Id AVP MUST be unique and Section 3.4. The value of the Session-Id AVP MUST be unique and
SHOULD be set according to the recommendations in Section 8.8 of RFC SHOULD be set according to the recommendations in Section 8.8 of RFC
3588. 3588 [RFC3588].
Message format: Message format:
<MPR> ::= < Diameter Header: CC3, REQ, PXY > <MPR> ::= < Diameter Header: CC3, REQ, PXY >
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Auth-Application-Id }
{ Auth-Session-State } { Auth-Session-State }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
skipping to change at page 8, line 37 skipping to change at page 9, line 51
4.4. Attribute Value Pairs (AVPs) 4.4. Attribute Value Pairs (AVPs)
This section describes the AVPs specific to the PCN Data Collection This section describes the AVPs specific to the PCN Data Collection
application. The 'M' bit MUST be set and the 'V' bit MUST NOT be set application. The 'M' bit MUST be set and the 'V' bit MUST NOT be set
for all of these AVPs when used in the PCN Data Collection for all of these AVPs when used in the PCN Data Collection
application. application.
4.4.1. I-E-Aggregate-Id AVP 4.4.1. I-E-Aggregate-Id AVP
The I-E-Aggregate-Id AVP (AVP code <AVP1>) is of type UTF8String. It The I-E-Aggregate-Id AVP (AVP code <AVP1>) is of type Grouped and
identifies a specific ingress-egress aggregate flow. The internal identifies a specific aggregate.
structure of the I-E-Aggregate-Id value is network dependent.
4.4.2. PCN-Congestion-Info AVP The I-E-Aggregate-Id AVP has the following format:
The PCN-Congestion-Info AVP (AVP code <AVP2>) is of type Grouped. It I-E-Aggregate-Id ::= < AVP Header: AVP1 >
[ PCN-Ingress-Node-Address ]
[ PCN-Egress-Node-Address ]
[ VLAN-ID-Range ]
* [ AVP ]
4.4.2. PCN-Ingress-Node-Address AVP
The PCN-Ingress-Node-Address AVP (AVP code <AVP2>) is of type Grouped
and contains the address of a PCN-Ingress-Node.
The PCN-Ingress-Node-Address AVP has the following format:
PCN-Ingress-Node-Address ::= < AVP Header: AVP2 >
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
4.4.3. PCN-Egress-Node-Address AVP
The PCN-Egress-Node-Address AVP (AVP code <AVP3>) is of type Grouped
and contains the address of a PCN-Egress-Node.
The PCN-Egress-Node-Address AVP has the following format:
PCN-Egress-Node-Address ::= < AVP Header: AVP3 >
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
4.4.4. Framed-IP-Address AVP
The Framed-IP-Address AVP is defined in the NASREQ application (RFC
4005 [RFC4005]).
4.4.5. Framed-IPv6-prefix AVP
The Framed-IPv6-prefix AVP is defined in the NASREQ application (RFC
4005 [RFC4005]).
4.4.6. VLAN-ID-Range AVP
The VLAN-ID-Range AVP, defined in ietf-dime-qos-attributes
[I-D.ietf-dime-qos-attributes], is of type Grouped and specifies the
VLAN range to match.
4.4.7. PCN-Congestion-Info AVP
The PCN-Congestion-Info AVP (AVP code <AVP4>) is of type Grouped. It
identifies an ingress-egress aggregate, reports the current value of identifies an ingress-egress aggregate, reports the current value of
the congestion level estimate (CLE), and indicates whether the report the congestion level estimate (CLE), and indicates whether the report
is generated because the CLE has risen above the reporting threshold is generated because the CLE has risen above the reporting threshold
or because it has fallen below the reporting threshold. or because it has fallen below the reporting threshold.
The PCN-Congestion-Info AVP has the following format: The PCN-Congestion-Info AVP has the following format:
PCN-Congestion-Info ::= < AVP Header: AVP2 > PCN-Congestion-Info ::= < AVP Header: AVP4 >
{ I-E-Aggregate-Id } { I-E-Aggregate-Id }
{ CLE-Value } { CLE-Value }
{ CLE-Report-Reason } { CLE-Report-Reason }
* [ AVP ] * [ AVP ]
4.4.3. CLE-Value AVP 4.4.8. CLE-Value AVP
The CLE-Value AVP (AVP code <AVP3>) is of type Float32. It gives the The CLE-Value AVP (AVP code <AVP5>) is of type Float32. It gives the
current (smoothed) congestion level estimate as a fraction between current (smoothed) congestion level estimate as a fraction between
0.0 and 1.0. 0.0 and 1.0.
4.4.4. CLE-Report-Reason AVP 4.4.9. CLE-Report-Reason AVP
The CLE-Report-Reason AVP (AVP code <AVP4>) is of type Enumerated. The CLE-Report-Reason AVP (AVP code <AVP6>) is of type Enumerated.
The following values are defined in this document: The following values are defined in this document:
PRECONGESTION_ONSET (0) PRECONGESTION_ONSET (0)
The current CLE (reported in CLE-Value) is above the configured The current CLE (reported in CLE-Value) is above the configured
onset reporting threshold. The CLE derived in the previous onset reporting threshold. The CLE derived in the previous
measurement period was below that threshold. measurement period was below that threshold.
PRECONGESTION_END (1) The current CLE (reported in CLE-Value) is PRECONGESTION_END (1) The current CLE (reported in CLE-Value) is
below the configured end-of-precongestion reporting threshold, below the configured end-of-precongestion reporting threshold,
which may have the same value as the onset reporting threshold. which may have the same value as the onset reporting threshold.
The CLE derived in the previous measurement period was above that The CLE derived in the previous measurement period was above that
threshold. threshold.
4.4.5. PCN-Excess-Flow-Info AVP 4.4.10. PCN-Excess-Flow-Info AVP
The PCN-Excess-Flow-Info AVP (AVP code <AVP5>) is of type Grouped. The PCN-Excess-Flow-Info AVP (AVP code <AVP7>) is of type Grouped.
It identifies an ingress-egress aggregate, reports a rate of excess It identifies an ingress-egress aggregate, reports a rate of excess
traffic for that aggregate, and MAY identify a number of individual traffic for that aggregate, and MAY identify a number of individual
flows within that aggregate that experienced the markings that led to flows within that aggregate that experienced the markings that led to
the generation of the PCN-Excess-Flow-Info AVP. Precise details of the generation of the PCN-Excess-Flow-Info AVP. Precise details of
the conditions under which this AVP is generated and how the the conditions under which this AVP is generated and how the
individual flows are selected are given in the specification for the indivdual flows are selected are given in the specification for the
PCN edge behavior deployed in the domain. PCN edge behaviour deployed in the domain.
The PCN-Excess-Flow-Info AVP has the following format: The PCN-Excess-Flow-Info AVP has the following format:
PCN-Excess-Flow-Info ::= < AVP Header: AVP5 > PCN-Excess-Flow-Info ::= < AVP Header: AVP7 >
{ I-E-Aggregate-Id } { I-E-Aggregate-Id }
{ I-E-Aggregate-Excess-Rate } { I-E-Aggregate-Excess-Rate }
* [ Flow Number ] * [ Classifier ]
* [ Flow Description ]
* [ AVP ] * [ AVP ]
4.4.6. I-E-Aggregate-Excess-Rate AVP 4.4.11. I-E-Aggregate-Excess-Rate AVP
The I-E-Aggregate-Excess-Rate AVP (AVP code <AVP6>) is of type The I-E-Aggregate-Excess-Rate AVP (AVP code <AVP8>) is of type
Unsigned32. It gives the rate of flow of excess traffic in octets Unsigned32. It gives the rate of flow of excess traffic in octets
per second that the egress node derived for the identified ingress- per second that the egress node derived for the identified ingress-
egress aggregate for the measurement period ending at the time given egress aggregate for the measurement period ending at the time given
by the Event-Timestamp AVP (if present). by the Event-Timestamp AVP (if present).
4.4.7. Flow-Number AVP 4.4.12. Classifier AVP
The Flow-Number AVP (Vendor code 10415, AVP code 509)
[ETSI-TS-129-209-V6.7.0] is of type Unsigned32, and it contains the
ordinal number of the IP flow(s). The rules for how the ordinal
number should be assigned are not described in this document.
4.4.8. Flow-Description AVP
The Flow-Description AVP (Vendor code 10415, AVP code 507)
[ETSI-TS-129-209-V6.7.0] is of type IPFilterRule, and defines a
packet filter for an IP flow with the following information:
o Direction (in or out).
o Source and destination IP address (possibly masked).
o Protocol.
o Source and destination port (list or ranges).
The b type SHALL be used with the following restrictions:
o Only the Action "permit" SHALL be used.
o No "options" SHALL be used.
o The invert modifier "!" for addresses SHALL not be used.
o The keyword "assigned" SHALL not be used.
The Flow-Description AVP SHALL be used to describe a single IP flow. The Classifier AVP (AVP Code TBD), defined in ietf-dime-qos-
The direction "in" refers to uplink IP flows, and the direction "out" attributes [I-D.ietf-dime-qos-attributes], is a grouped AVP that
refers to downlink IP flows. consists of a set of attributes that specify how to match a packet.
4.4.9. PCN-Sent-Info AVP 4.4.13. PCN-Sent-Info AVP
The PCN-Sent-Info AVP (AVP code <AVP7>) is of type Grouped. It The PCN-Sent-Info AVP (AVP code <AVP9>) is of type Grouped. It
provides the rate of flow of PCN-marked traffic in octets per second provides the rate of flow of PCN-marked traffic in octets per second
that the ingress node derived for the identified ingress-egress that the ingress node derived for the identified ingress-egress
aggregate for the measurement period ending at the time given by the aggregate for the measurement period ending at the time given by the
Event-Timestamp AVP (if present). Event-Timestamp AVP (if present).
The PCN-Sent-Info AVP has the following format: The PCN-Sent-Info AVP has the following format:
PCN-Sent-Info ::= < AVP Header: AVP7 > PCN-Sent-Info ::= < AVP Header: AVP9 >
{ I-E-Aggregate-Id } { I-E-Aggregate-Id }
{ I-E-Aggregate-Sent-Rate } { I-E-Aggregate-Sent-Rate }
* [ AVP ] * [ AVP ]
4.4.10. I-E-Aggregate-Sent-Rate AVP 4.4.14. I-E-Aggregate-Sent-Rate AVP
The I-E-Aggregate-Sent-Rate AVP (AVP code <AVP8>) is of type The I-E-Aggregate-Sent-Rate AVP (AVP code <AVP10>) is of type
Unsigned32. It gives the rate of flow of PCN-marked traffic in Unsigned32. It gives the rate of flow of PCN-marked traffic in
octets per second that the ingress node forwarded to the identified octets per second that the ingress node forwarded to the identified
ingress-egress aggregate, calculated for the measurement period ingress-egress aggregate, calculated for the measurement period
ending at the time given by the Event-Timestamp AVP (if present). ending at the time given by the Event-Timestamp AVP (if present).
4.5. Procedures 4.5. AVP Occurrence Tables
The following subsections discuss the processing requirements placed
upon the various participating Diameter nodes by the PCN Data
Collection application.
4.5.1. Overall Procedures
The egress node measures the traffic from a particular ingress node,
and calculates the congestion level estimate(CLE) at the ingress-
egress aggregate level. The egress node may compare the CLE
calculated at the current interval with the CLE calculated at the
last interval, if the difference of the two CLEs exceeds a preset
range, the egress node sends the feedback information, including at
least the current CLE, to the PDP. After receiving the feedback
information, the PDP saves the it for admission control and flow
termination. After receiving a service flow request, the PDP can
determine whether to admit the request or not based on the feedback
information. Besides, the PDP also decides whether some of the
admitted flows need to be terminated. The PDP needs to signal to the
ingress node the decision about admission or termination.
4.5.2. Egress Node behavior
For each ingress-egress aggregate flow it serves, the egress node The following tables present the AVPs defined in this document and
meters received traffic for PCN markings, recomputes its smoothed their occurrences in Diameter messages. Note that AVPs that can only
congestion level estimate, and determines whether there is excess be present within a Grouped AVP are not represented in this table.
flow in successive measurement periods in accordance with the PCN
edge behavior specification deployed in the domain. When a change in
the smoothed congestion level estimate causes it to cross a reporting
threshold, either upward or downward, the egress node MUST send a
Congestion-Report-Request message to the PDP. Similarly, the egress
node MUST send a Congestion-Report-Request message to the PDP when
excess flow is detected for an ingress-egress aggregate served by
that node.
The Event-Timestamp AVP SHOULD be present, and SHOULD provide the The table uses the following symbols:
ending time of the measurement period from which the data triggering
the generation of the message were derived. At least one instance
either of the PCN-Congestion-Info or the PCN-Excess-Flow-Info AVP
MUST be present. Both AVPs MAY be present for the same ingress-
egress aggregate, if both apply according to the edge behavior
specification. Multiple instances of either AVP MAY be present, but
each instance MUST report on a different ingress-egress aggregate.
4.5.3. PDP behavior 0: The AVP MUST NOT be present in the message.
If the PDP receives an Congestion-Report-Request (CRR) identified as 0+: Zero or more instances of the AVP MAY be present in the
belonging to the PCN Data Collection application, it MUST acknowledge message.
the message with an Congestion-Report-Answer (CRA). The PDP usage of
the information provided by PCN-Congestion-Info and PCN-Excess-Flow-
Info AVPs is described in the applicable edge behavior specification.
When the PDP receives an CRR containing an PCN-Excess-Flow-Info AVP, 0-1: Zero or one instance of the AVP MAY be present in the
it MAY send a Measurement-Poll-Request (MPR) to the ingress node for message.
the aggregate concerned. The I-E-Aggregate-Id MUST identify the
ingress-egress aggregate flow for which information is being
requested. The Event-Timestamp MUST be present if it was present in
the CRR that contained the PCN-Excess-Flow-Info AVP, and MUST have
the same value.
If the PDP receives a successful Measurement-Poll-Answer message, it 1: One instance of the AVP MUST be present in the message.
uses the information contained in the PCN-Sent-Info AVP as described
in the applicable edge behavior specification.
4.5.4. Ingress Node behavior +-----------------------+
| Command-Code |
|-----+-----+-----+-----+
AVP Name | CRR | CRA | MPR | MPA |
-------------------------------|-----+-----+-----+-----+
PCN-Congestion-Info | 0+ | 0 | 0 | 0 |
PCN-Excess-Flow-Info | 0+ | 0 | 0 | 0 |
PCN-Sent-Info | 0 | 0 | 0 | 1 |
I-E-Aggregate-Id | (*) | 0 | 1 | (*) |
+-----+-----+-----+-----+
When an ingress node receives an MPR, it MUST generate a Measurement- (*): Note that the I-E-Aggregate-Id AVP appears alone in the MPR
Poll-Answer message containing an instance of the PCN-Sent-Info AVP. command and within the PCN-Sent-Info grouped AVP (MPA command), the
The I-E-Aggregate-Id within the PCN-Sent-Info AVP MUST be the same as PCN-Excess-Flow-Info AVP, and the PCN-Congestion-Info AVP.
received in the MPR, and the I-E-Aggregate-Sent-Rate MUST be a rate
measured for that aggregate. If Event-Timestamp is present in the
MPR, the measurement upon which I-E-Aggregate-Sent-Rate is based
SHOULD be that for the latest measurement period ending before or at
the time given by Event-Timestamp, if available. In any case, Event-
Timestamp SHOULD be present in the MPA, and if it is, MUST give the
end-time of the measurement period upon which I-E-Aggregate-Sent-Rate
is based.
5. IANA Considerations 5. IANA Considerations
Upon publication of this memo as an RFC, IANA is requested to assign Upon publication of this memo as an RFC, IANA is requested to assign
values as described in the following sections. values as described in the following sections.
5.1. Diameter Application Identifier 5.1. Diameter Application Identifier
An application identifier for Diameter PCN Data Collection (<AID>, An application identifier for Diameter PCN Data Collection (<AID>,
Section 4.1) must be assigned according to the policy specified in Section 4.1) must be assigned according to the policy specified in
Section 11.3 of RFC 3588. Section 11.3 of RFC 3588 [RFC3588].
5.2. Diameter Command Codes 5.2. Diameter Command Codes
Codes must be assigned for the following commands according to the Codes must be assigned for the following commands according to the
policy specified in RFC 3588, Section 11.2.1: policy specified in RFC 3588 [RFC3588], Section 11.2.1:
o Congestion-Report-Request (CRR) (<CC1>, Section 4.3.1) o Congestion-Report-Request (CRR) (<CC1>, Section 4.3.1)
o Congestion-Report-Answer (MPA) (<CC1>, Section 4.3.2) o Congestion-Report-Answer (MPA) (<CC2>, Section 4.3.2)
o Measurement-Poll-Request (MPR) (<CC2>, Section 4.3.3) o Measurement-Poll-Request (MPR) (<CC3>, Section 4.3.3)
o Measurement-Poll-Answer (MPA) (<CC2>, Section 4.3.4) o Measurement-Poll-Answer (MPA) (<CC4>, Section 4.3.4)
5.3. Attribute-Value Pairs 5.3. Attribute-Value Pairs
Codes must be assigned for the following AVPs using the policy Codes must be assigned for the following AVPs using the policy
specified in RFC 3588, Section 11.1.1: specified in RFC 3588 [RFC3588], Section 11.1.1:
o I-E-Aggregate-Id (<AVP1>, Section 4.4.1) o I-E-Aggregate-Id (<AVP1>, Section 4.4.1)
o PCN-Congestion-Info (<AVP2>, Section 4.4.2) o PCN-Ingress-Node-Address (<AVP2>, Section 4.4.2)
o CLE-Value (<AVP3>, Section 4.4.3) o PCN-Egress-Node-Address (<AVP3>, Section 4.4.3)
o CLE-Report-Reason (<AVP4>, Section 4.4.4) o PCN-Congestion-Info (<AVP4>, Section 4.4.7)
o PCN-Excess-Flow-Info (<AVP5>, Section 4.4.5) o CLE-Value (<AVP5>, Section 4.4.8)
o I-E-Aggregate-Excess-Rate (<AVP6>, Section 4.4.6) o CLE-Report-Reason (<AVP6>, Section 4.4.9)
o PCN-Sent-Info (<AVP7>, Section 4.4.9) o PCN-Excess-Flow-Info (<AVP7>, Section 4.4.10)
o I-E-Aggregate-Sent-Rate (<AVP8>, Section 4.4.10) o I-E-Aggregate-Excess-Rate (<AVP8>, Section 4.4.11)
o PCN-Sent-Info (<AVP9>, Section 4.4.13)
o I-E-Aggregate-Sent-Rate (<AVP10>, Section 4.4.14)
6. Security Considerations 6. Security Considerations
The following sections discuss the security threats against the The following sections discuss the security threats against the
Diameter PCN Data Collection application and describe some Diameter PCN Data Collection application and describe some
countermeasures. countermeasures.
6.1. Traffic Security 6.1. Traffic Security
Application traffic MUST be secured as specified in RFC 3588 (i.e.,, Application traffic MUST be secured as specified in RFC 3588
through the use of (preferably) TLS or IPsec). In the absence of [RFC3588] (i.e., through the use of (preferably) TLS or IPsec). In
appropriate protection, all manner (including man-in-the-middle) of the absence of appropriate protection, all manner (including man-in-
attacks are possible, potentially resulting in the inappropriate the-middle) of attacks are possible, potentially resulting in the
termination and non-admittance of flows. inappropriate termination and non-admittance of flows.
6.2. Device Security 6.2. Device Security
Compromise of an ingress node by an attacker could result in the Compromise of an ingress node by an attacker could result in the
inappropriate refusal of admittance to valid flows, while the inappropriate refusal of admittance to valid flows, while the
compromise of an egress node could allow the termination of valid compromise of an egress node could allow the termination of valid
flows. flows.
Compromise of the PDP could result in both denial of admission to new Compromise of the PDP could result in both denial of admission to new
flows and termination of existing flows, enabling an attacker to flows and termination of existing flows, enabling an attacker to
essentially control PCN traffic on the affected network. essentially control PCN traffic on the affected network.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-dime-qos-attributes]
Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
and A. Lior, "Quality of Service Attributes for Diameter",
draft-ietf-dime-qos-attributes-13 (work in progress),
July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
7.2. Informative References 7.2. Informative References
[ETSI-TS-129-209-V6.7.0] [I-D.ietf-pcn-cl-edge-behaviour]
ETSI, "Universal Mobile Telecommunications System (UMTS); Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
Policy control over Gq interface (3GPP TS 29.209 version Taylor, "PCN Boundary Node Behaviour for the Controlled
6.7.0 Release 6)", ETSI TS 129.209 V6.7.0 (2007-06), Load (CL) Mode of Operation",
June 2007. draft-ietf-pcn-cl-edge-behaviour-00 (work in progress),
July 2009.
[I-D.ietf-pcn-sm-edge-behaviour]
Charny, A., Karagiannis, G., Menth, M., and T. Taylor,
"PCN Boundary Node Behaviour for the Single Marking (SM)
Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-00
(work in progress), July 2009.
[Q.3303.3] [Q.3303.3]
ITU-T, "Resource control protocol No. 3 -- Protocols at ITU-T, "Resource control protocol No. 3 -- Protocols at
the Rw interface between a policy decision physical entity the Rw interface between a policy decision physical entity
(PD-PE) and a policy enforcement physical entity (PE-PE): (PD-PE) and a policy enforcement physical entity (PE-PE):
Diameter", May 2008, Diameter", May 2008,
<http://www.itu.int/rec/T-REC-Q.3303.3>. <http://www.itu.int/rec/T-REC-Q.3303.3>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface [RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface
Application", RFC 5431, March 2009. Application", RFC 5431, March 2009.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009. Architecture", RFC 5559, June 2009.
Appendix A. Related Work in ITU-T
The ITU-T is doing work to exploit the PCN technology in an
environment where the decisions are made by a central policy decision
point (PDP) [Q.3303.3], which needs the information generated by PCN
marking to support per-flow decisions on admission and termination.
This memo defines a Diameter application to transfer the information
from edge nodes to the PDP. Egress node reports are sent by the
egress node acting as client to the PDP acting as server. Data
generated at the ingress node are needed only when flow termination
is required. They are requested by the PDP acting as client and sent
in responses by the ingress node acting as server. The PDP thus acts
both as client and as server in the same application. The Rw
application [RFC5431] provides a precedent for such an application.
The PCN Data Collection application is related to existing ITU-T
applications as follows:
o The Rs application allows application-level functions to request
flow admission for individual application flows.
o The Rw application provides the control linkage between a Policy
Decision Point and an ingress router, to pass down decisions on
flow admission following either the push or the pull model. The
Rw application also passes flow termination decisions.
As can be seen from this brief description, the PCN Data Collection
application defined in this memo is complementary to the Rw
application. Within the strict terms of the ITU-T architecture, it
is a realization of a different interface, the Rc interface.
However, the PCN Data Collection application is intended for use in
any of a number of architectures based on a centralized policy
decision element.
Authors' Addresses Authors' Addresses
Fortune Huang Fortune Huang
Huawei Technologies Huawei Technologies
Section F Section F
Huawei Industrial Base Huawei Industrial Base
Bantian Longgang, Shenzhen 518129 Bantian Longgang, Shenzhen 518129
P.R. China P.R. China
Email: fqhuang@huawei.com Email: fqhuang@huawei.com
skipping to change at line 668 skipping to change at page 18, line 4
Glen Zorn (editor) Glen Zorn (editor)
Network Zen Network Zen
1310 East Thomas Street 1310 East Thomas Street
#306 #306
Seattle, Washington 98102 Seattle, Washington 98102
USA USA
Phone: +1 (206) 377-9035 Phone: +1 (206) 377-9035
Email: gwz@net-zen.net Email: gwz@net-zen.net
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
 End of changes. 76 change blocks. 
252 lines changed or deleted 330 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/