< draft-huang-dime-pcn-collection-00.txt   draft-huang-dime-pcn-collection-01.txt >
Network Working Group F. Huang Network Working Group F. Huang
Internet-Draft Huawei Technologies Internet-Draft T. Taylor
Intended status: Standards Track G. Zorn, Ed. Intended status: Standards Track Huawei Technologies
Expires: January 7, 2010 Network Zen Expires: January 13, 2010 G. Zorn, Ed.
July 6, 2009 Network Zen
July 12, 2009
The Diameter Precongestion Notification (PCN) Data Collection The Diameter Precongestion Notification (PCN) Data Collection
Application Application
draft-huang-dime-pcn-collection-00 draft-huang-dime-pcn-collection-01
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 34 skipping to change at page 1, line 35
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 7, 2010. This Internet-Draft will expire on January 13, 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
4. The Diameter PCN Data Collection Application . . . . . . . . . 5 4. The Diameter PCN Data Collection Application . . . . . . . . . 5
4.1. Advertising Application Support . . . . . . . . . . . . . 5 4.1. Advertising Application Support . . . . . . . . . . . . . 5
4.2. Diameter Session Usage . . . . . . . . . . . . . . . . . . 5 4.2. Diameter Session Usage . . . . . . . . . . . . . . . . . . 5
4.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3.1. Congestion-Report-Request (CRR) Command . . . . . . . 6 4.3.1. Congestion-Report-Request (CRR) Command . . . . . . . 6
4.3.2. Congestion-Report-Answer (CRA) Command . . . . . . . . 6 4.3.2. Congestion-Report-Answer (CRA) Command . . . . . . . . 6
4.3.3. Measurement-Poll-Request (MPR) Command . . . . . . . . 7 4.3.3. Measurement-Poll-Request (MPR) Command . . . . . . . . 7
4.3.4. Measurement-Poll-Answer (MPA) Command . . . . . . . . 7 4.3.4. Measurement-Poll-Answer (MPA) Command . . . . . . . . 8
4.4. Attribute Value Pairs (AVPs) . . . . . . . . . . . . . . . 8 4.4. Attribute Value Pairs (AVPs) . . . . . . . . . . . . . . . 8
4.4.1. I-E-Aggregate-Id AVP . . . . . . . . . . . . . . . . . 8 4.4.1. I-E-Aggregate-Id AVP . . . . . . . . . . . . . . . . . 8
4.4.2. PCN-Congestion-Info AVP . . . . . . . . . . . . . . . 8 4.4.2. PCN-Congestion-Info AVP . . . . . . . . . . . . . . . 8
4.4.3. CLE-Value AVP . . . . . . . . . . . . . . . . . . . . 8 4.4.3. CLE-Value AVP . . . . . . . . . . . . . . . . . . . . 9
4.4.4. CLE-Report-Reason AVP . . . . . . . . . . . . . . . . 9 4.4.4. CLE-Report-Reason AVP . . . . . . . . . . . . . . . . 9
4.4.5. PCN-Excess-Flow-Info AVP . . . . . . . . . . . . . . . 9 4.4.5. PCN-Excess-Flow-Info AVP . . . . . . . . . . . . . . . 9
4.4.6. I-E-Aggregate-Excess-Rate AVP . . . . . . . . . . . . 9 4.4.6. I-E-Aggregate-Excess-Rate AVP . . . . . . . . . . . . 10
4.4.7. Flow Number AVP . . . . . . . . . . . . . . . . . . . 9 4.4.7. Flow-Number AVP . . . . . . . . . . . . . . . . . . . 10
4.4.8. Flow Description . . . . . . . . . . . . . . . . . . . 10 4.4.8. Flow-Description AVP . . . . . . . . . . . . . . . . . 10
4.4.9. PCN-Sent-Info AVP . . . . . . . . . . . . . . . . . . 10 4.4.9. PCN-Sent-Info AVP . . . . . . . . . . . . . . . . . . 10
4.4.10. I-E-Aggregate-Sent-Rate AVP . . . . . . . . . . . . . 11 4.4.10. I-E-Aggregate-Sent-Rate AVP . . . . . . . . . . . . . 11
4.5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5.1. Overall Procedures . . . . . . . . . . . . . . . . . . 11 4.5.1. Overall Procedures . . . . . . . . . . . . . . . . . . 11
4.5.2. Egress Node Behaviour . . . . . . . . . . . . . . . . 11 4.5.2. Egress Node behavior . . . . . . . . . . . . . . . . . 11
4.5.3. PDP Behaviour . . . . . . . . . . . . . . . . . . . . 12 4.5.3. PDP behavior . . . . . . . . . . . . . . . . . . . . . 12
4.5.4. Ingress Node Behaviour . . . . . . . . . . . . . . . . 12 4.5.4. Ingress Node behavior . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . 13
5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 13 5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Traffic Security . . . . . . . . . . . . . . . . . . . . . 14 6.1. Traffic Security . . . . . . . . . . . . . . . . . . . . . 14
6.2. Device Security . . . . . . . . . . . . . . . . . . . . . 14 6.2. Device Security . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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
skipping to change at page 5, line 48 skipping to change at page 5, line 48
Measurement-Poll-Answer (MPA) messages. Measurement-Poll-Answer (MPA) messages.
4.2. Diameter Session Usage 4.2. Diameter Session Usage
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- 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
The PCN Data Collection application defines four new commands, The PCN Data Collection application defines four new commands,
Congestion-Report-Request(CRR), Congestion-Report-Answer(CRA), Congestion-Report-Request(CRR), Congestion-Report-Answer(CRA),
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
skipping to change at page 6, line 29 skipping to change at page 6, line 29
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 4.5.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 }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
[ Destination-Host ] [ Destination-Host ]
[ 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. 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
Section 8.8 of RFC 3588.
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 <CC1> 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:
<CRA> ::= < Diameter Header: CC1, PXY > <CRA> ::= < Diameter Header: CC2, PXY >
< Session-Id > < Session-Id >
{ Auth Application Id } { Auth-Application-Id }
{ Auth-Session-State }
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ Error-Message ] [ Error-Message ]
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
[ Failed-AVP ] [ Failed-AVP ]
[ Event-Timestamp ] [ Event-Timestamp ]
* [ 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 <CC2> 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. Section 4.5.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
3588.
Message format: Message format:
<MPR> ::= < Diameter Header: CC2, REQ, PXY > <MPR> ::= < Diameter Header: CC3, REQ, PXY >
< Session-Id > < Session-Id >
{ Auth Application Id } { Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ I-E-Aggregate-Id } { I-E-Aggregate-Id }
[ Destination-Host ] [ Destination-Host ]
[ Event-Timestamp ] [ Event-Timestamp ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ AVP ] * [ AVP ]
4.3.4. Measurement-Poll-Answer (MPA) Command 4.3.4. Measurement-Poll-Answer (MPA) Command
The ingress node sends the Measurement-Poll-Answer (MPA) command, The ingress node sends the Measurement-Poll-Answer (MPA) command,
indicated by the Command-Code field set to <CC2> and the Command indicated by the Command-Code field set to <CC4> and the Command
Flags' 'R' bit cleared, in response to an MPR sent by the PDP. Flags' 'R' bit cleared, in response to an MPR sent by the PDP.
Message format: Message format:
<MPA> ::= < Diameter Header: CC2, PXY > <MPA> ::= < Diameter Header: CC4, PXY >
< Session-Id > < Session-Id >
{ Auth Application Id } { Auth-Application-Id }
{ Auth-Session-State }
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ PCN-Sent-Info } { PCN-Sent-Info }
[ Error-Message ] [ Error-Message ]
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
[ Failed-AVP ] [ Failed-AVP ]
[ Event-Timestamp ] [ Event-Timestamp ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
skipping to change at page 9, line 29 skipping to change at page 9, line 41
threshold. threshold.
4.4.5. PCN-Excess-Flow-Info AVP 4.4.5. 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 <AVP5>) 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
indivdual flows are selected are given in the specification for the individual flows are selected are given in the specification for the
PCN edge behaviour deployed in the domain. PCN edge behavior 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: AVP5 >
{ I-E-Aggregate-Id } { I-E-Aggregate-Id }
{ I-E-Aggregate-Excess-Rate } { I-E-Aggregate-Excess-Rate }
* [ Flow Number ] * [ Flow Number ]
* [ Flow Description ] * [ Flow Description ]
* [ AVP ] * [ AVP ]
4.4.6. I-E-Aggregate-Excess-Rate AVP 4.4.6. 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 <AVP6>) 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.7. Flow-Number AVP
The Flow Number AVP (AVP code 509) is of type Unsigned32, and it The Flow-Number AVP (Vendor code 10415, AVP code 509)
contains the ordinal number of the IP flow(s). The rules for how the [ETSI-TS-129-209-V6.7.0] is of type Unsigned32, and it contains the
ordinal number should be assigned are not described in this document. 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 4.4.8. Flow-Description AVP
The Flow Description AVP (AVP code 507) is of type IPFilterRule, and The Flow-Description AVP (Vendor code 10415, AVP code 507)
defines a packet filter for an IP flow with the following [ETSI-TS-129-209-V6.7.0] is of type IPFilterRule, and defines a
information: packet filter for an IP flow with the following information:
o Direction (in or out). o Direction (in or out).
o Source and destination IP address (possibly masked). o Source and destination IP address (possibly masked).
o Protocol. o Protocol.
o Source and destination port (list or ranges). o Source and destination port (list or ranges).
The b type shall be used with the following restrictions: The b type SHALL be used with the following restrictions:
o Only the Action "permit" shall be used. o Only the Action "permit" SHALL be used.
o No "options" shall be used. o No "options" SHALL be used.
o The invert modifier "!" for addresses shall not be used. o The invert modifier "!" for addresses SHALL not be used.
o The keyword "assigned" 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 Flow-Description AVP SHALL be used to describe a single IP flow.
The direction "in" refers to uplink IP flows, and the direction "out" The direction "in" refers to uplink IP flows, and the direction "out"
refers to downlink IP flows. refers to downlink IP flows.
4.4.9. PCN-Sent-Info AVP 4.4.9. PCN-Sent-Info AVP
The PCN-Sent-Info AVP (AVP code <AVP7>) is of type Grouped. It The PCN-Sent-Info AVP (AVP code <AVP7>) 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: AVP8 > PCN-Sent-Info ::= < AVP Header: AVP7 >
{ 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.10. 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 <AVP8>) 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
skipping to change at page 11, line 35 skipping to change at page 11, line 44
last interval, if the difference of the two CLEs exceeds a preset last interval, if the difference of the two CLEs exceeds a preset
range, the egress node sends the feedback information, including at range, the egress node sends the feedback information, including at
least the current CLE, to the PDP. After receiving the feedback least the current CLE, to the PDP. After receiving the feedback
information, the PDP saves the it for admission control and flow information, the PDP saves the it for admission control and flow
termination. After receiving a service flow request, the PDP can termination. After receiving a service flow request, the PDP can
determine whether to admit the request or not based on the feedback determine whether to admit the request or not based on the feedback
information. Besides, the PDP also decides whether some of the information. Besides, the PDP also decides whether some of the
admitted flows need to be terminated. The PDP needs to signal to the admitted flows need to be terminated. The PDP needs to signal to the
ingress node the decision about admission or termination. ingress node the decision about admission or termination.
4.5.2. Egress Node Behaviour 4.5.2. Egress Node behavior
For each ingress-egress aggregate flow it serves, the egress node For each ingress-egress aggregate flow it serves, the egress node
meters received traffic for PCN markings, recomputes its smoothed meters received traffic for PCN markings, recomputes its smoothed
congestion level estimate, and determines whether there is excess congestion level estimate, and determines whether there is excess
flow in successive measurement periods in accordance with the PCN flow in successive measurement periods in accordance with the PCN
edge behaviour specification deployed in the domain. When a change edge behavior specification deployed in the domain. When a change in
in the smoothed congestion level estimate causes it to cross a the smoothed congestion level estimate causes it to cross a reporting
reporting threshold, either upward or downward, the egress node MUST threshold, either upward or downward, the egress node MUST send a
send an Accounting-Request message to the PDP. Similarly, the egress Congestion-Report-Request message to the PDP. Similarly, the egress
node MUST send an Accounting-Request message to the PDP when excess node MUST send a Congestion-Report-Request message to the PDP when
flow is detected for an ingress-egress aggregate served by that node. excess flow is detected for an ingress-egress aggregate served by
The Session-Id is irrelevant to the PCN Data Collection application that node.
and MAY have any value that conforms to [RFC3588]. The Account-
Record-Type for the message MUST be set to EVENT_RECORD (1). The
Accounting-Record-Number AVP SHOULD be set to 0.
The Event-Timestamp AVP SHOULD be present, and SHOULD provide the The Event-Timestamp AVP SHOULD be present, and SHOULD provide the
ending time of the measurement period from which the data triggering ending time of the measurement period from which the data triggering
the generation of the message were derived. At least one instance the generation of the message were derived. At least one instance
either of the PCN-Congestion-Info or the PCN-Excess-Flow-Info AVP 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- MUST be present. Both AVPs MAY be present for the same ingress-
egress aggregate, if both apply according to the edge behaviour egress aggregate, if both apply according to the edge behavior
specification. Multiple instances of either AVP MAY be present, but specification. Multiple instances of either AVP MAY be present, but
each instance MUST report on a different ingress-egress aggregate. each instance MUST report on a different ingress-egress aggregate.
4.5.3. PDP Behaviour 4.5.3. PDP behavior
If the PDP receives an Accounting-Request (ACR) identified as If the PDP receives an Congestion-Report-Request (CRR) identified as
belonging to the PCN Data Collection application, it MUST acknowledge belonging to the PCN Data Collection application, it MUST acknowledge
the message with an Accounting-Answer (ACA). The PDP usage of the the message with an Congestion-Report-Answer (CRA). The PDP usage of
information provided by PCN-Congestion-Info and PCN-Excess-Flow-Info the information provided by PCN-Congestion-Info and PCN-Excess-Flow-
AVPs is described in the applicable edge behaviour specification. Info AVPs is described in the applicable edge behavior specification.
When the PDP receives an ACR containing an PCN-Excess-Flow-Info AVP, When the PDP receives an CRR containing an PCN-Excess-Flow-Info AVP,
it MAY send a Measurement-Poll-Request (MPR) to the ingress node for it MAY send a Measurement-Poll-Request (MPR) to the ingress node for
the aggregate concerned. The Account-Record-Type for the message the aggregate concerned. The I-E-Aggregate-Id MUST identify the
MUST be set to EVENT_RECORD (1). The I-E-Aggregate-Id MUST identify ingress-egress aggregate flow for which information is being
the ingress-egress aggregate flow for which information is being
requested. The Event-Timestamp MUST be present if it was present in requested. The Event-Timestamp MUST be present if it was present in
the ACR that contained the PCN-Excess-Flow-Info AVP, and MUST have the CRR that contained the PCN-Excess-Flow-Info AVP, and MUST have
the same value. the same value.
If the PDP receives a successful Measurement-Poll-Answer message, it If the PDP receives a successful Measurement-Poll-Answer message, it
uses the information contained in the PCN-Sent-Info AVP as described uses the information contained in the PCN-Sent-Info AVP as described
in the applicable edge behaviour specification. in the applicable edge behavior specification.
4.5.4. Ingress Node Behaviour 4.5.4. Ingress Node behavior
When an ingress node receives an MPR, it MUST generate a Measurement- When an ingress node receives an MPR, it MUST generate a Measurement-
Poll-Answer message containing an instance of the PCN-Sent-Info AVP. Poll-Answer message containing an instance of the PCN-Sent-Info AVP.
The Account-Record-Type for the message MUST be set to EVENT_RECORD The I-E-Aggregate-Id within the PCN-Sent-Info AVP MUST be the same as
(1). The Accounting-Record-Number AVP SHOULD be set to 0. 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 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 measured for that aggregate. If Event-Timestamp is present in the
MPR, the measurement upon which I-E-Aggregate-Sent-Rate is based MPR, the measurement upon which I-E-Aggregate-Sent-Rate is based
SHOULD be that for the latest measurement period ending before or at SHOULD be that for the latest measurement period ending before or at
the time given by Event-Timestamp, if available. In any case, Event- 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 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 end-time of the measurement period upon which I-E-Aggregate-Sent-Rate
is based. is based.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 13, line 18 skipping to change at page 13, line 18
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.
5.2. Diameter Command Codes 5.2. Diameter Command Codes
Command codes must be assigned for Congestion-Report-Request (CRR) Codes must be assigned for the following commands according to the
(<CC1>, Section 4.3.1), Congestion-Report-Answer (MPA) (<CC1>, policy specified in RFC 3588, Section 11.2.1:
Section 4.3.2), Measurement-Poll-Request (MPR) (<CC2>, Section 4.3.3)
and Measurement-Poll-Answer (MPA) (<CC2>, Section 4.3.4) commands o Congestion-Report-Request (CRR) (<CC1>, Section 4.3.1)
according to the policy specified in RFC 3588, Section 11.2.1.
o Congestion-Report-Answer (MPA) (<CC1>, Section 4.3.2)
o Measurement-Poll-Request (MPR) (<CC2>, Section 4.3.3)
o Measurement-Poll-Answer (MPA) (<CC2>, 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, Section 11.1.1:
I-E-Aggregate-Id (<AVP1>, Section 4.4.1) o I-E-Aggregate-Id (<AVP1>, Section 4.4.1)
PCN-Congestion-Info (<AVP2>, Section 4.4.2) o PCN-Congestion-Info (<AVP2>, Section 4.4.2)
CLE-Value (<AVP3>, Section 4.4.3) o CLE-Value (<AVP3>, Section 4.4.3)
CLE-Report-Reason (<AVP4>, Section 4.4.4) o CLE-Report-Reason (<AVP4>, Section 4.4.4)
PCN-Excess-Flow-Info (<AVP5>, Section 4.4.5) o PCN-Excess-Flow-Info (<AVP5>, Section 4.4.5)
I-E-Aggregate-Excess-Rate (<AVP6>, Section 4.4.6) o I-E-Aggregate-Excess-Rate (<AVP6>, Section 4.4.6)
PCN-Sent-Info (<AVP7>, Section 4.4.9) o PCN-Sent-Info (<AVP7>, Section 4.4.9)
I-E-Aggregate-Sent-Rate (<AVP8>, Section 4.4.10) o I-E-Aggregate-Sent-Rate (<AVP8>, Section 4.4.10)
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
countermeasues. countermeasures.
6.1. Traffic Security 6.1. Traffic Security
Application taffic MUST be secured as specified in RFC 3588 (i.e.,, Application traffic MUST be secured as specified in RFC 3588 (i.e.,,
through the use of (preferably) TLS or IPsec). In the absence of through the use of (preferably) TLS or IPsec). In the absence of
appropriate protection, all manner (including man-in-the-middle) of appropriate protection, all manner (including man-in-the-middle) of
attacks are possible, potentially resulting in the inappropriate attacks are possible, potentially resulting in the inappropriate
termination and non-adittance of flows. 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
skipping to change at page 14, line 36 skipping to change at page 14, line 42
7.1. Normative References 7.1. Normative References
[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.
7.2. Informative References 7.2. Informative References
[ETSI-TS-129-209-V6.7.0]
ETSI, "Universal Mobile Telecommunications System (UMTS);
Policy control over Gq interface (3GPP TS 29.209 version
6.7.0 Release 6)", ETSI TS 129.209 V6.7.0 (2007-06),
June 2007.
[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.
skipping to change at page 15, line 16 skipping to change at page 15, line 29
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
Tom Taylor
Huawei Technologies
1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8
Canada
Phone: +1 613 680 2675
Email: tom.taylor@rogers.com
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
 End of changes. 61 change blocks. 
89 lines changed or deleted 114 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/