PCN                                                              T. Tsou
Internet-Draft                                                 T. Taylor
Expires: May 20, 2008                                             Huawei
                                                       November 17, 2007

                      PCN Boundary Node Behaviour

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 20, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Tsou & Taylor             Expires May 20, 2008                  [Page 1]

Internet-Draft         PCN Boundary Node Behaviour         November 2007


   The Pre-Congestion Notification Architecture document defines a PCN
   domain and the PCN-ingress and PCN-egress nodes that form its
   boundary.  The present document is an attempt to describe the
   detailed behaviour of the PCN boundary nodes.  It is a contribution
   toward the PCN WG milestone: "Suggested Flow Admission and
   Termination Boundary Mechanisms".  This first version is expected to
   evolve with discussion and further thought toward a more precise and
   prescriptive view of boundary node behaviour.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of Boundary Node Functions  . . . . . . . . . . . . .  5
   4.  Details of Boundary Node Functions . . . . . . . . . . . . . .  7
     4.1.  PCN-ingress-node Functions . . . . . . . . . . . . . . . .  7
     4.2.  PCN-egress-node Functions  . . . . . . . . . . . . . . . .  8
     4.3.  Peer Address Determination and Flow Aggregation  . . . . .  9
   5.  Communication Behavior between Boundary Nodes  . . . . . . . . 11
     5.1.  PCN-ingress-node to PCN-egress-node  . . . . . . . . . . . 11
     5.2.  PCN-egress-node to PCN-ingress-node  . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Tsou & Taylor             Expires May 20, 2008                  [Page 2]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

1.  Introduction

   The Pre-Congestion Notification Architecture document [I-D.PCNarch]
   defines a PCN domain and the PCN-ingress and PCN-egress nodes that
   form its boundary.  The present document is an attempt to describe
   the detailed behaviour of the PCN boundary nodes.  As part of this
   effort, it deals with the following issues:

   o  mapping from flows to aggregates;

   o  discovery of peer addresses;

   o  processing of observations at the PCN-egress-node;

   o  transmission policy for congestion level estimates (CLE).

Tsou & Taylor             Expires May 20, 2008                  [Page 3]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

   The formal definitions of "PCN-domain", "PCN-boundary-node", "PCN-
   interior-node", "PCN-ingress-node" and "PCN-egress-node" are given in
   section 2 of [I-D.PCNarch].  These terms are used here, generally
   without the hyphens, to have the same meaning.

   This memo uses the following abbreviations:

   CE     Congestion Experienced (ECN marking)

   CLE    Congestion level estimates

   DSCP   Differentiated Services Codepoint

   ECMP   Equal cost multi-path

   ECN    Explicit congestion notification

   PCN    Pre-congestion notification

Tsou & Taylor             Expires May 20, 2008                  [Page 4]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

3.  Overview of Boundary Node Functions

   A PCN domain is a self-controlled group of nodes, some of which, the
   PCN boundary nodes, connect the PCN domain to other network domains.
   PCN boundary nodes play an extremely important role in the
   implementation of the PCN mechanism; they are in charge of flow
   admission and flow termination so as to protect the existing payload
   within the PCN domain.  PCN boundary nodes fulfill two functional
   roles, those of PCN-ingress-node and of PCN-egress-node.  A given
   flow enters the PCN domain through the PCN-ingress-node and leaves it
   through the PCN-egress-node.  In physical terms, the flow passes
   through an ingress-egress pair.  This natural pairing of the PCN
   boundary nodes through which a given flow passes is bi-directional:
   the PCN boundary node that serves as the PCN-ingress-node for one
   flow also serves as the PCN-egress-node for a flow in the opposite
   direction and vice versa.

   As [I-D.PCNarch] specifies, a PCN domain is a Diffserv domain.  There
   are different priority traffic classes within the PCN domain.  When a
   flow is presented to the PCN domain, the PCN-ingress-node should
   figure out whether it is a PCN flow or not.  If it is, the PCN-
   ingress-node marks the flow packets accordingly.  When these packets
   leave the domain, the PCN-egress-node should remove the PCN markings
   so they do not confuse a subsequent domain.

   It is obvious that the PCN-ingress-node supports flow recognition.
   This is a necessity if the PCN-ingress-node is to enforce flow
   admission and termination (policy action).

   The PCN-egress-node measures the aggregate flow for each PCN-ingress/
   PCN-egress pair for which it is the PCN-egress-node.  In some
   circumstances, the PCN-egress-node should also support flow
   recognition.  At present, we do not require this, for reasons of
   scalability and simplicity.  If the PCN-egress-node did measure each
   individual flow, it would add too much cost to the cached flow table.

   As part of its measurements for a given ingress-egress aggregate, the
   PCN-egress-node obtains information relating to congestion level
   estimates (CLE).  The PCN-egress-node sends the CLE in a message to
   the PCN-ingress-node or to a node acting as centralized collection
   point.  The strategy for when the CLE messages are sent is discussed
   in Section 5.2.  The PCN-ingress-node or the centralized collector
   node acting on its behalf makes flow admission or termination
   judgements based on these CLE messages.

   When the aggregate flow from some PCN-ingress-node contains no
   traffic or too low a traffic level, no measurement or too inaccurate
   measurement of congestion can be performed.  No CLE message can be

Tsou & Taylor             Expires May 20, 2008                  [Page 5]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

   sent or the CLE message sent is too inaccurate to make the right
   decision.  In this case the PCN-ingress-node needs to send a probe
   message to the PCN-egress-node to gain more information.  According
   to the design requirement, ECMP within a PCN domain can also best be
   resolved by a probe message.  For the sake of efficiency, the probing
   operation requires careful design to ensure that it does not
   significantly affect the existing load within the domain.  Current
   discussion has concluded that probing is a topic that should be
   considered after the basic mechanisms have been defined.

   The following sections deal with three major topics.  Section 4 is a
   detailed functional definition of the PCN-ingress-node and PCN-
   egress-node.  This part will draw upon the existing content of
   [I-D.PCNarch], but will identify specific issues that have to be
   addressed.  Section 4.3 deals with the specific issues of flow-to-
   aggregate mapping and peer address determination.  Finally, Section 5
   considers the control and communication messaging that must occur
   between the PCN-ingress-node and PCN-egress-node.

Tsou & Taylor             Expires May 20, 2008                  [Page 6]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

4.  Details of Boundary Node Functions

4.1.  PCN-ingress-node Functions

   The PCN-ingress-node enforces flow admission and flow termination
   decisions on flows offered to the PCN domain.  Quoting from section
   5.2 of [I-D.PCNarch], its functions are:

   o  Packet classify

   o  Police

   o  PCN-color

   o  PCN-meter

   These basic actions imply some additional requirements on the PCN-

   a.  The PCN-ingress-node should know the address of the PCN-egress-
       node for each new flow request that arrives.  This is the key
       that allows the PCN-ingress-node to select the applicable CLE
       information from the messages it has received.  See Section 4.3
       for a discussion of how the PCN-ingress-node and PCN-egress-node
       determine each other's address and associate individual flows to
       the aggregate flow between them.

   b.  When the admission decision function is implemented in the PCN-
       ingress-node, that node should know the congestion level to each
       PCN-egress-node to which it has admitted flows.  This is needed
       to perform flow admission and flow termination.  Generally, the
       PCN-ingress-node should possess the latest congestion level
       information.  The information is saved and refreshed periodically
       as new CLE messages are received.  If too long a period elapses
       without receipt of congestion level information from a given PCN-
       egress-node, the PCN-ingress-node may have to take an active part
       in gathering the information, by polling or by sending a probing

          It would seem undesirable to add to network load by polling or
          probing unless there is a decision to be made.  Admission
          decisions (and consequent probes) are covered by the preceding
          bullet.  The one case that may require thought is where CLE
          messages fail to get through because of congestion in the
          egress-to-ingress direction, and this is matched by congestion
          in the ingress-to-egress direction that would call for flow

Tsou & Taylor             Expires May 20, 2008                  [Page 7]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

       Although it is out of scope of the current charter, the admission
       decision function may be implemented in a centralized control
       node.  CLE maintenance and refreshment will then be the
       responsibility of this centralized node.  In that case, the PCN-
       ingress-node will act as a policy enforcement point only,
       admitting or rejecting flow in accord with the policy provided by
       the centralized control node.

   c.  Currently, the PCN architectural requirements do not include
       support of ECN.  [I-D.PCNarch] spells out the present assumptions
       about the interaction between ECN and PCN.

   d.  When the PCN-ingress-node terminates a flow, it should send a
       signaling message to notify the flow source about the congestion
       condition and reason for termination.

4.2.  PCN-egress-node Functions

   The PCN-egress-node is in charge of aggregate flow measurement and
   emission of CLE messages.  The basic functions of the PCN-egress-node
   are listed in [I-D.PCNarch]: packet classify, PCN-meter, and PCN-
   color -- but this section adds more details.

   a.  Packet classify - determine which PCN-ingress-node a PCN-packet
       has come from.  This is a requirement of measurement.  After
       packet classification, all packets arriving at the PCN-egress-
       node are grouped into their respective ingress-egress aggregate
       flows.  In the case of tunnelled packets, the PCN-egress-node
       differentiates ingress nodes according to the ingress node
       address in tunnel encapsulation header.  Otherwise the PCN-
       egress-node must use the source address and possibly other
       information within the packet header.

       In this latter case, the PCN-egress-node must in concept keep a
       boundary node address table, in which it saves the PCN-ingress-
       node address and flow source/destination prefix mapping.  By
       searching on the flow source/destination address, the PCN-egress-
       node can get the PCN-ingress-node address.  For a discussion on
       how this table can be set up, see Section 4.3.

   b.  PCN-meter - make "measurements of PCN-traffic".  The measurements
       are made on the aggregate flow of all PCN-packets from a
       particular PCN-ingress-node.  Smoothing is done over time, using
       for example the EWMA (Exponentially Weighted Moving Average)
       method applied separately to numerator and denominator of the
       congestion ratio.  The measurement period for individual
       observations requires careful calculation.  Shorter measurement
       periods increase the amount of computation required at the PCN-

Tsou & Taylor             Expires May 20, 2008                  [Page 8]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

       egress-node while increasing the volatility of the results.  Too
       long a measurement period reduces the responsiveness of the
       system to signs of approaching congestion.  Smoothing has a
       similar effect to lengthening the measurement period, but gives
       more weight to more recent measurements.

       Instead of smoothing, one might consider looking at the process
       as one of statistical estimation of a marking probability that is
       step-wise time-varying.  One assesses each new observation to
       decide whether it represents a continuation of the previous
       regime or is the result of a new value of the estimated
       probability.  The decision would use a standard deviation based
       on the assumption of a binomial probability distribution.

       Once the PCN-marking rate calculations have been carried out, the
       PCN-egress-node must send a CLE message back to the PCN-ingress-
       node providing the results.  Again there is a requirement to know
       the peer address.  See Section 4.3.

   c.  PCN-color - for PCN-packets, set the DSCP field or DSCP and ECN
       fields to the appropriate value(s) for use outside the PCN-

4.3.  Peer Address Determination and Flow Aggregation

   Both at ingress and at egress the boundary nodes are faced with the
   problem of classifying flows by aggregate.  As mentioned in the
   previous section, this is conceptually equivalent to having a table
   in each node, mapping source/destination prefix pair to the identity
   of the peer node.  Using tunnels between ingress and egress requires
   the equivalent information, since otherwise the ingress node does not
   know the tunnel to which a given flow should be directed.  The PCN-
   egress-node must in addition have a mapping from the PCN-ingress-node
   identity to its address.  This mapping is trivial if the node address
   is used to represent its identity.

   The table just described is equivalent to the information required to
   establish full-mesh direct routing between the boundary nodes.  It
   seems unfortunate if it is really necessary to bypass the
   information-hiding benefits of routing through interior nodes.  Let
   us consider the possibilities for acquiring the necessary mappings,
   to see if we can do better.

   o  The mappings could be installed in each boundary node by
      configuration.  This raises obvious concerns for scalability and
      responsiveness to changes in the external prefixes served by each
      boundary node.

Tsou & Taylor             Expires May 20, 2008                  [Page 9]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

   o  The mappings could be acquired by an automatic peer-to-peer
      discovery procedure tied to the exchange of routing data within
      the PCN-domain.

   o  The mapping for each flow could be determined as it is offered to
      the PCN-ingress-node, through use of an RSVP PATH message or NSIS

   The first two methods have the disadvantage that they require the
   persistent storage of a full mapping table at each boundary node.
   Their advantage is that they would require less messaging and
   associated resource consumption than the third approach.  Moreover,
   when a new flow is offered to the PCN-ingress-node, it is in a
   position to make an immediate decision to admit or not, rather than
   having to wait a round-trip for a response from the PCN-egress-node.

   The third method, per-flow mapping query, works best if flows tend to
   be focussed between specific ingress-egress pairs rather than spread
   uniformly around the network.  The per-flow burden will be reduced to
   the extent that flow mappings can be cached and reused at the ingress
   and egress nodes.  Since in general new flows will not be between the
   same source and destination addresses as existing ones, reusability
   of the mapping data requires that the information exchanged between
   the ingress and egress nodes be in the form of the prefixes routed
   through the respective nodes rather than the specific addresses
   involved in the flow that triggered the information exchange.

   While the use of one or more centralized collector nodes is out of
   scope of the current PCN charter, one can visualize a system wherein
   such nodes acquire the list of served prefixes from each boundary
   node and provide aggregate identifiers in response to per-flow
   queries from ingress and egress nodes.  The collector nodes receive
   the CLE messages from the PCN-egress-nodes, with metered results
   presented for each aggregate identifier active at the egress node.
   They forward the CLE results to the PCN-ingress-nodes after mapping
   from aggregate identifier to PCN-ingress-node address.  It would be
   desirable not to exclude this model of operation when creating the
   basic PCN design.

Tsou & Taylor             Expires May 20, 2008                 [Page 10]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

5.  Communication Behavior between Boundary Nodes

5.1.  PCN-ingress-node to PCN-egress-node

   The discussion of the previous section suggests that, except when
   configuration is used to provide the flow-to-aggregate and
   aggregate-to peer address mappings, the PCN-ingress-node will have to
   send some sort of message to the PCN-egress-node to establish these
   mappings, for a specific flow or all flows that could occur between
   them.  We have already remarked on the possible use of the RSVP PATH
   message (modified to carry source prefix information as well as the
   specific source and destination addresses) in the ingree-to-egress
   direction on a per-flow basis.  In the reverse direction, the RESV
   (which may contain a CLE message) would carry the destination prefix
   served by the PCN-egress-node.  Whether the prefix information in
   each direction is merely the range within which the specific source
   or destination address of the flow lies or the complete set of
   prefixes served by the respective node is for further discussion.

   In addition to the creation of mappings, the PCN-ingress-node may
   also send probe messages to the PCN-egress-node.  Current list
   discussion seems to lean toward putting off any consideration of
   probing in our initial work, but we may come back to it in the
   future.  Probe messages are useful when there is no traffic between
   ingress and egress or too little traffic for the PCN-egress-node to
   measure accurately.  Probing would be initiated at the PCN-ingress-
   node if after mapping an offered flow to an aggregate it found stale
   or no CLE information for that aggregate.  The design of the probing
   operation should consider the appropriate action if there is
   excessiive delay in receiving the probe response.

5.2.  PCN-egress-node to PCN-ingress-node

   The messaging that the PCN-egress-node may have to do as part of the
   flow-to-aggregate mapping procedure has already been discussed.  The
   previous section also suggested that the PCN-egress-node will have to
   respond to probe messages.  The nature of that response depends on
   the particular marking behaviour and algorithms used in the network.

   Aside from helping to generate mappings and responding to probes, the
   PCN-egress-node must report the results of its measurements.  As
   indicated already, this is done by sending a CLE message to each PCN-
   ingress-node (or to a central collector node on its behalf).  The
   content of these messages provides the basis for the PCN-ingress-node
   or some other policy entity to make flow admission or flow
   termination decisions.

   One question that must be addressed is: when should the CLE message

Tsou & Taylor             Expires May 20, 2008                 [Page 11]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

   be sent?  There are three basic possibilities:

   o  The CLE message is sent in response to polling by the PCN-ingress-
      node.  An interesting variant of this is that the trigger for
      sending the CLE is receipt of an RSVP PATH message or NSIS
      equivalent, sent to acquire the mapping between a specific flow
      and an aggregate.  The CLE information would thus be made
      available precisely when it is needed to make the admission
      decision.  This fails to take care of the requirements for flow
      termination, however, so something more would be needed.

   o  The second possibility is that the CLE message is sent
      autonomously whenever the congestion level estimate crosses pre-
      configured lower and upper thresholds.  Because of the lack of
      information redundancy in the CLE messages transmitted compared
      the other methods, this approach requires that the CLE message be
      delivered reliably.  This method could be used to supplement the
      polling approach described in the previous bullet, with the CLE
      messages being sent autonomously only for transitions across the
      upper threshold.

   o  The final possibility is that the CLE message is sent periodically
      at a fixed interval.  This method is more robust than the others
      when CLE messages go missing, since the PCN-ingress-node has past
      data which it can extrapolate until the next measurement arrives.

Tsou & Taylor             Expires May 20, 2008                 [Page 12]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

6.  Security Considerations

   PCN-ingress-node and PCN-egress-node dealing with DDOS attack and
   similarities.  When DDOS attack arrives at PCN-ingress-node.  PCN-
   ingress-node should figure them out and take some action to protect
   the existing payload and itself from failure.

Tsou & Taylor             Expires May 20, 2008                 [Page 13]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

7.  IANA Considerations

   This memo presents no IANA considerations.

Tsou & Taylor             Expires May 20, 2008                 [Page 14]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

8.  Acknowledgements

   Thanks to Gabriele Corliano for ideas contributed in preliminary
   discussion, and to Philip Eardley for an excellent review of an
   earlier version of this memo.

Tsou & Taylor             Expires May 20, 2008                 [Page 15]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

9.  References

9.1.  Normative References

              Eardley, P., "Pre-Congestion Notification Architecture",
              October 2007.

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

9.2.  Informative References

              Chan, K. and G. Karagiannis, "Pre-Congestion Notification
              Encoding Comparison", July 2007.


              (Work in progress.)

              Briscoe, B., "Pre-Congestion Notification Encoding
              Comparison", October 2006.


              (Expired work in progress.)

   [RFC1633]  Braden, B., Clark, D., and S. Shenker, "Integrated
              Services in the Internet Architecture: an Overview",
              RFC 1633, June 1994.

Tsou & Taylor             Expires May 20, 2008                 [Page 16]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

Authors' Addresses

   Tina Tsou
   Huawei Technologies
   F3-5-089S, R&D Center,
   Longgang District
   Shenzhen  518129

   Email: tena@huawei.com

   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave
   Ottawa, Ontario  K1H 6Z8

   Phone: +1 613 680 2675
   Email: tom.taylor@rogers.com

Tsou & Taylor             Expires May 20, 2008                 [Page 17]

Internet-Draft         PCN Boundary Node Behaviour         November 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Tsou & Taylor             Expires May 20, 2008                 [Page 18]