[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                           T. Taylor, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Informational                             March 8, 2010
Expires: September 9, 2010


                  The PCN Piggybacking Edge Behaviour
            draft-taylor-pcn-piggybacking-edge-behaviour-01

Abstract

   Precongestion notification (PCN) is a means for protecting quality of
   service for inelastic traffic admitted to a Diffserv domain.  The
   overall PCN architecture is described in RFC 5559.  This memo
   describes a behaviour for PCN egress nodes known as the
   "piggybacking" edge behaviour, because it "piggybacks" PCN
   information in resource signalling messages.  This version of the
   memo describes two alternatives, where piggybacking is derived from
   the CL edge behaviour and where it is derived from the SM edge
   behaviour.  The SM and CL edge behaviours are specified in companion
   documents.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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.

   This Internet-Draft will expire on September 9, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the



Taylor                  Expires September 9, 2010               [Page 1]


Internet-Draft         Piggybacking Edge Behaviour            March 2010


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Assumed Signalling Behaviour  . . . . . . . . . . . . . . . . . 4
   3.  Assumed Behaviour at Interior Nodes . . . . . . . . . . . . . . 4
   4.  Edge Node Behaviours  . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Egress Node Behaviour . . . . . . . . . . . . . . . . . . . 4
       4.1.1.  Data Collection . . . . . . . . . . . . . . . . . . . . 4
       4.1.2.  Reporting . . . . . . . . . . . . . . . . . . . . . . . 5
     4.2.  Ingress Node Behaviour  . . . . . . . . . . . . . . . . . . 6
     4.3.  Decision Point Behaviour  . . . . . . . . . . . . . . . . . 6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7



















Taylor                  Expires September 9, 2010               [Page 2]


Internet-Draft         Piggybacking Edge Behaviour            March 2010


1.  Introduction

   The main objective of Pre-Congestion Notification (PCN) is to support
   the quality of service (QoS) of inelastic flows within a Diffserv
   domain, in a simple, scalable, and robust fashion.  Two mechanisms
   are used: admission control and flow termination.  Admission control
   is used to decide whether to admit or block a new flow request, while
   flow termination is used in abnormal circumstances to decide whether
   to terminate some of the existing flows.  To support these two
   features the overall rate of PCN-traffic is metered on every link in
   the domain, and PCN-packets are appropriately marked when certain
   configured rates are exceeded.  These configured rates are below the
   rate of the link thus providing notification to boundary nodes about
   overloads before any congestion occurs (hence "pre-congestion"
   notification).  The level of marking allows decisions to be made
   about whether to admit or terminate individual flows.  For more
   details see [RFC5559].

   Boundary node behaviours specify a detailed set of algorithms and
   edge node behaviours used to implement the PCN mechanisms.  The
   piggybacking edge behaviour which is the subject of this memo
   introduces no new behaviours and algorithms beyond those provided by
   the SM and CL edge behaviours ([I-D.SM-Edge-Behaviour] and
   [I-D.CL-Edge-Behaviour] respectively).  Instead, it provides an
   alternative method of signalling whereby the egress node reports the
   rates it has calculated as an addition to resource signalling rather
   than using a separate protocol.  This has implications both for the
   operation of the resource signalling and the operation of the PCN
   mechanisms.

1.1.  Terminology

   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 [RFC2119].

   In addition to the terms defined in [RFC5559], this document uses the
   following terms:

   decision point
      The node that makes the decision about which flows to admit and to
      terminate.  In a given network deployment, this may be the ingress
      node or a centralized control node.  Decisions are enforced by the
      ingress node.  In contrast to the signalling architecture
      considered in [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour],
      in the piggybacking case the egress node always sends its
      information to the ingress node rather than the decision point.
      The ingress node then forwards the PCN reports to the decision



Taylor                  Expires September 9, 2010               [Page 3]


Internet-Draft         Piggybacking Edge Behaviour            March 2010


      point if they are not collocated.  The decision point returns its
      decisions to the ingress node as usual.

   NM-Rate, ThM-Rate, ETM-Rate
      The calculated rate at which PCN traffic has been received in
      unmarked packets, threshold-marked packets (CL mode only), and
      excess-traffic-marked packets respectively.  See the descriptions
      of egress node behaviour in [I-D.SM-Edge-Behaviour] and
      [I-D.CL-Edge-Behaviour] for further details.


2.  Assumed Signalling Behaviour

   For the piggybacking edge behaviour, it is assumed that applications
   are using a resource signalling protocol (e.g., RSVP, NSIS) to
   request resources from the network.  The PCN domain is viewed as a
   building block in the complete end-to-end path.  Resource signalling
   is processed by the edge nodes of the PCN domain, but not by the
   interior nodes.  Thus the passage from the PCN-ingress-node to the
   PCN-egress-node or vice versa is viewed as a single hop.

   It is assumed that a request for resources for a given flow requires
   at least one message passing through the PCN-egress-node toward the
   PCN-ingress-node.  This is consistent with RSVP and some cases of
   NSIS, but rules out "Basic Sender Initiated Reservation" as described
   in Section 4.1 of [I-D.NSLP].


3.  Assumed Behaviour at Interior Nodes

   It is assumed that nodes interior to the PCN domain do not
   participate in the resource signalling, but simply forward that
   signalling toward the edge.  Beyond that, the applicable assumptions
   are as described in [I-D.SM-Edge-Behaviour] and
   [I-D.CL-Edge-Behaviour] respectively.


4.  Edge Node Behaviours

4.1.  Egress Node Behaviour

4.1.1.  Data Collection

   The PCN-egress-node MUST meter received PCN traffic per ingress-
   egress-aggregate and periodically calculate the rate at which
   unmarked, threshold-marked (for the CL behaviour), and excess-
   traffic-marked traffic is received, all as described in
   [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour] respectively.



Taylor                  Expires September 9, 2010               [Page 4]


Internet-Draft         Piggybacking Edge Behaviour            March 2010


   The interval between successive calculations SHOULD be a constant
   value of the order of 100 to 500 ms, as described in the CL and SM
   documents.

   If so configured, when operating in CL mode, the PCN-egress-node MUST
   also save the identities of flows experiencing excess-traffic-marking
   during the latest measurement interval.

4.1.2.  Reporting

   The PCN-egress-node reports its measured results according to the
   following rules:

   o  When the PCN-egress-node receives resource signalling for a new
      flow, it processes that message according to the rules of the
      protocol.  However, if the message is to be forwarded in the
      direction of the PCN-ingress-node, the egress node MUST add to the
      message an object containing its latest calculated values of NM-
      rate, ThM-Rate (for CL mode only) and ETM-Rate for the ingress-
      egress-aggregate which that flow would join.  In addition, if
      operating in CL mode and so configured, if the ETM-Rate is greater
      than zero the PCN-egress-node SHOULD add to the message an object
      identifying individual flows within the aggregate that experienced
      excess-traffic marking.

         There may not be space for this within the message.

   o  If the PCN-egress-node receives resource signalling refreshing
      state for an established flow, it again processes the message
      according to the rules of the protocol.  OPEN ISSUE: Should it
      attach the latest values of the calculated rates, or should it
      attach the values that were placed into the original message
      establishing that flow?  The latter was suggested by
      [I-D.lefaucheur-rsvp-ecn], to make it easier for implementations
      to distinguish refresh messages.

   o  If the calculated ETM-Rate for an interval is greater than zero
      and no resource signalling in the direction of the PCN-ingress-
      node was received during that interval relating to the ingress-
      egress-aggregate concerned, the PCN-egress-node SHOULD generate an
      autonomous report identifying the ingress-egress-aggregate, giving
      the calculated values of NM-Rate, ThM-Rate, and ETM-Rate, and, if
      so configured, a list of individual flows that were excess-
      traffic-marked in the interval just concluded.

         The condition of no message in the right direction in the
         previous interval is a heuristic for predicting whether one
         will come along in the next interval.



Taylor                  Expires September 9, 2010               [Page 5]


Internet-Draft         Piggybacking Edge Behaviour            March 2010


         OPEN ISSUE 1: can this use a message within the resource
         protocol?  RSVP messages are associated with individual flows.
         Can an RSVP session between ingress and egress be set up
         specifically for the aggregate, so that messages like this
         relate to the aggregate as a whole?

         OPEN ISSUE 2: does the message have to be delivered reliably?

4.2.  Ingress Node Behaviour

   When the PCN-ingress-node receives resource signalling from the
   direction of the PCN-egress-node, it processes the message as
   required by the resource protocol.  Before forwarding it, it removes
   any PCN-related information added by the egress node and forwards
   that information to the decision point.

      If the ingress node and the decision point are collocated, the
      exchanges between them are an internal operation.

   The PCN-ingress-node MUST provide the estimated current rate of
   admitted PCN traffic (octets per second) for a specific ingress-
   egress-aggregate when the decision point requests it, as described in
   [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour].

4.3.  Decision Point Behaviour

   Behaviour at the decision point is exactly as documented in
   [I-D.SM-Edge-Behaviour] or [I-D.CL-Edge-Behaviour] as applicable.


5.  Acknowledgements

   draft-lefaucheur-rsvp-ecn-01.txt ([I-D.lefaucheur-rsvp-ecn]) covered
   this ground in much greater detail, three and a half years ago.  The
   author borrowed some of the information from that document, but the
   document itself should probably be revised to fit the present shape
   of PCN if there is interest in this work.


6.  IANA Considerations

   This memo includes no request to IANA.


7.  Security Considerations

   To be written.




Taylor                  Expires September 9, 2010               [Page 6]


Internet-Draft         Piggybacking Edge Behaviour            March 2010


8.  References

8.1.  Normative References

   [I-D.CL-Edge-Behaviour]
              Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
              Taylor, Ed., "PCN Boundary Node Behaviour for the
              Controlled Load (CL) Mode of Operation (Work in
              progress)", 2010.

   [I-D.SM-Edge-Behaviour]
              Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T.
              Taylor, Ed., "PCN Boundary Node Behaviour for the Single
              Marking (SM) Mode of Operation (Work in progress)", 2010.

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

8.2.  Informative References

   [I-D.NSLP]
              Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
              Quality-of-Service Signaling (Work in progress)",
              January 2010.

   [I-D.lefaucheur-rsvp-ecn]
              Le Faucheur, F., Charny, A., Briscoe, B., Eardley, P.,
              Chan, K., and J. Babiarz, "RSVP Extensions for Admission
              Control   over Diffserv using Pre-congestion Notification
              (PCN) (Work in progress)", June 2006.

   [RFC5559]  Eardley, P., "Pre-Congestion Notification (PCN)
              Architecture", RFC 5559, June 2009.


Author's Address

   Tom Taylor (editor)
   Huawei Technologies
   1852 Lorraine Ave
   Ottawa
   Canada

   Email: tom111.taylor@bell.net







Taylor                  Expires September 9, 2010               [Page 7]