Transport Area Working Group                               J. Adams
Internet-Draft                                          Razoom, Inc
Intended status: Informational
Expires: March 1st, 2010
                                                  September 15, 2009

   Flow State Aware signalling standardisation, and a proposal for
      alerting nodes or end-systems on data related to a flow
         draft-adams-tsvwg-flow-signaling-identification-00



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 March 1st, 2010.

















Adams                   Expires March 1st , 2010                [Page 1]


Internet-Draft        FSA Signal Packet Identification    September 2009


Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.









































Adams                   Expires March 1st , 2010                [Page 2]


Internet-Draft        FSA Signal Packet Identification    September 2009


Abstract

This document describes the motivation for Flow State Aware signalling
and proposes a method of enabling Flow State Aware signalling packets
to be identified.














































Adams                     Expires March 1st, 2010               [Page 3]


Internet-Draft        FSA Signal Packet Identification    September 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Motivation and Early Deployment Scenarios for FSA QoS  . . . .  5
   3.  Architectural considerations . . . . . . . . . . . . . . . . .  7
   4.  Evolution considerations  . . . . . . . . . . . . . . . . . . . 8
   5.  FSA Signalling Standards Development . . . . . . . . . . . . .  9
   6.  Signal Packet Identification     . . . . . . . . . . . . . . . 10
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   10. Informative References   . . . . . . . . . . . . . . . . . . . 12








































Adams                     Expires March 1st, 2010               [Page 4]


Internet-Draft        FSA Signal Packet Identification    September 2009


1. Introduction

This internet draft informs on the benefits of Flow State Aware (FSA)
signalling, both as an ehancement of flow classification and, longer-
term, as the engine to create new network capabilities.

This internet draft also informs on an existing proposal for Flow State
Aware signal packet identification, and calls for further evaluation
of such proposals and a recommendation of the best solution by the
IETF.


2. Motivation and Early Deployment Scenarios for FSA QoS

Flow State Aware (FSA) technology operates at the per-flow level and
provides functions to manage the QoS and monitoring actions that may
be required on a specific flow. It distinguishes itself from Deep
Packet Inspection and WAN Optimisation functions in that it supports
FSA Transport Classes, i.e.
  - the Maximim Rate (MR) class. Allowing a flow to start with no
    admission control and protecting other flows from any disturbance
    to their QoS experience through "remembering" and directing
    discard actions on this flow (until conditions change).
  - the Guaranteed Rate (GR) class. A class of flows that are protected
    from discard actions under normal operating conditions.
  - the Available Rate (AR) class. A class of flows that are supported
    by signalling tests of the current fastest end-to-end available
    rate
  - the Variable Rate (VR) class. A class of flows with a minimum rate
    (in the same sense as an MR-level of guarantee) plus an additional
    available-rate "top-up".


FSA associates flow state with every flow (potentially) in any aggregate
of flows and/or the aggregate itself. It uses this state information to
perform the following:
   2.1  QoS actions on any flow. In particular
        2.1.1 Admission-based actions - allowing a flow to start but
              promoting it to QoS guarantees when resources are
              available.
        2.1.2 Preference-based actions - controlling how soon a flow
              is promoted to QoS guarantees
        2.1.3 Focused packet discards. "Remembering" flows whose
              packets are subject to some level of discard.
        2.1.4 Guaranteed QoS. "Remembering" flows whose packets are
              not to be subjected to any discard under normal
              operating conditions.
        2.1.5 Additional QoS actions if end-to-end Flow State Aware
              signalling is operating. In particular:
              2.1.5.1  Available Rate assignment of capacity. Based

Adams                     Expires March 1st, 2010               [Page 5]


Internet-Draft        FSA Signal Packet Identification    September 2009

              on the signalling yielding the fastest end-to-end
              available rate.
   2.2  Measurement actions on any flow or any flow aggregate. In
        particular:
        2.2.1 Per-flow or per-aggregate flow policing, as required.
        2.2.2 Per-flow or per-aggregate flow alerts, based on a
              measured parameter, and where the alert may trigger:
              2.2.2.1  A change of state (per flow, per aggregate)
              2.2.2.2  A change of QoS action
              2.2.2.3  A change of monitoring action
        2.2.3 Per-flow or per-aggregate flow alerts, based on a
              packet classifier parameter, and where the alert may
              trigger:
              2.2.3.1  A change of state (per flow, per aggregate)
              2.2.3.2  A change of QoS action
              2.2.3.3  A change of monitoring action

This internet draft focuses on signalling development associated
with flow state (through which the above action 2.1 and 2.2 are
then managed). First it may be noted that not all of the actions above
actually require any signalling. For example, 2.1.1 can allow a flow
to start immediately, regardless of whether any signalling had been
received related to that flow. But it would still require some actions
related to flow classification so that the flow was properly
classified as "needing QoS guarantees". Similarly, 2.1.2 could be done
entirely with the aid of flow classification and no signalling.

Furthermore performing flow classification on high speed (10 Gbit/s)
input links is possible (and is already being done) so no claim can be
made that signalling is a necessary addition to make the classifiers
operate at 10 Gbit/s or higher.

Essentially the argument for signalling is twofold:
A. Extending the information about what we know about a flow or what
   we want done to a flow.
B. Enabling path tests, such as the Available Rate path test.

In the next section of this internet draft, some future possibilities
are listed that could extend what is being signalled and which add to
the argument that an FSA signalling capability can do more than a
classifier ever could do on its own.


It is clear that a richer level of information could be associated with
a flow if flow-based signalling accompanies that flow. This would be
true at any level of classifier processing power. By "accompanied" we
could mean either in-band or path-coupled, but in-band seems to be the
choice that causes the least processing hit, and opens up new
possibilities like high-speed transfers based on the fastest available
rate.


Adams                     Expires March 1st, 2010               [Page 6]


Internet-Draft        FSA Signal Packet Identification    September 2009

An investigation into the use of GIST [1] as the signal transport
for FSA yielded the following observations:

  - FSA is a signal from one node to all downstream FSA nodes in
    the path of the flow. GIST is a signal between two nodes.
  - GIST utilises UDP encapsulation. FSA uses the same type of
    encapsulation as is used for the data packets of the flow.

3. Architectural considerations

Reference [2] defines a Flow State Aware Signalling Edge Function. This
is a function that provides the origin and/ or termination of the Flow
State Aware end-to-end signalling path, and participates in requests
and responses on behalf of a user application or management action. It
may be located, for example, in a user end-system or at a network edge
node where it serves as the signalling end-point of multiple users and
associated applications. Alternatively, it may be located at an
Aggregation End-point where it supports the signalling requirements of
flow aggregates.

Figure 1 shows an overview of FSA functions




 ---------        ---------        -----------        ------------
| Non-FSA |      | FSA     |      |    FSA    |      |Aggregation |
| End-    |---<--| End-    |---<--|Signalling |---<--| End-point  |--<-
| System  |--->--|System   |--->--|   Edge    |--->--| Function   |-->-
|Functions|      |Functions|      |           |      |            |
 ---------        ---------        -----------        ------------


            Figure 1: FSA Functional architecture


In Figure 1 an FSA End-System is shown with QoS and/ or monitoring
capabilities but with no Signalling Edge Function. Of course, it is
envisaged that End-Systems may evolve so that they may have:
  -  no FSA capabilities (as is the case today)
  -  limited FSA capabilities, for example at an End-System Hub
  -  Evolved FSA capabilities, including FSA signalling

The Aggregation End-point is a function which attaches or deletes the
common Flow Aggregate Identifiers to ensure commencement of/ cessation
of common routing and QoS treatment of packets. This end-point also
initiates/ terminates in-band signalling to control Flow State
information retained for treatment of the flow aggregate.

The implication of FSA signals terminating on a FSA Signalling Edge
Function (including Aggregation End-point functions) is that the End

Adams                     Expires March 1st, 2010               [Page 7]


Internet-Draft        FSA Signal Packet Identification    September 2009

Systems that are receiving or sending data do not receive extra packets
(i.e. the signalling packets) that may otherwise cause data corruption
or other problems relating to TCP or UDP transmission. Instead, the only
packets that are forwarded further downstream from a FSA signalling Edge
Function are the user-data packets.

At the far right-hand side of Figure 1 is shown both-way multiple packet
flows going either downstream towards an End-System via a FSA Signalling
Edge Function, or upstream towards a far-end Aggregation End Point
function and far-end FSA Signalling Edge Function.

The FSA functions shown in Figure 1 may include layer 2 or layer 3
packet forwarding capability. Thus an example of a FSA function in
Figure 1 could be:
  -  an Ethernet frame-forwarding function that is "IP aware"
  -  a router

4. Evolution considerations

More insight can be gained by looking at an early FSA deployment
scenario and considering an evolution of this that includes FSA
signalling and what is then added to the value.


(a) First stage: Stand-alone Flow State Aware functions managing the
    access bandwidth, QoS experience and monitoring actions associated
    with broadband service.

    Without signalling, such a solution could focus on 2.1.1, 2.1.2,
    2.1.3, 2.1.4, and 2.2.

(b) Second stage of evolution: With signalling on some flows only.
    Allows the support all of 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2, plus
    2.1.5 in the following limited sense:
       - some flows are being controlled end-to-end if distributed
         content services utilise FSA managed access bandwidth and
         the content sources can transmit towards the users just
         using an access network.
       - some flows are not associated with any signalling and are
         managed as in evolution stage (a)
       - signalling (where used) increases the information available
         per flow or simplifies and extends the setting of preference
         priority or peak rate without a large number of classifier
         rules.

(c) Third stage: (Could also be a second stage without signalling)
    Access FSA functions are interconnected by fixed-bandwidth trunks
    and:
    -  Without signalling, such a solution could focus on 2.1.1, 2.1.2,
       2.1.3, 2.1.4, and 2.2. (but with limited information, e.g. on
       preference priority or peak rates).

Adams                     Expires March 1st, 2010               [Page 8]


Internet-Draft        FSA Signal Packet Identification    September 2009

    -  With signalling, extends the number of sources that can signal
       flow information towards an FSA QoS management function and
       utilise signal-supported services such as AR or VR.

(d) Forth stage of evolution: Signalling on most flows, where some
    sources are anywhere on the internet. Allows access to FSA signal-
    supported QoS and monitoring capabilities for content providers who
    have not built out content distribution to match scenario (b) or (c)
    above.


(e) Fifth stage of evolution: extensions to the signalling to
    incorporate further new capabilities (see next section).


Note that priority Assignment allows the sender to request the priority
that the sender needs for each flow. For Emergency Services, Military
use, and corporate use the ability for a user to assign different rate
priorities to each flow is critical. If the flow may be available rate,
the rate would then be assigned based on the priority. For maximum rate
flows, the priority could allow critical flows the rate they need. This
capability must be coupled with authorization security for the user to
use this priority.

Authorization security for a sender to use a given priority can be
verified with a AAA server but must be assured for each flow to insure
security. Per packet assurance is considered infeasible and/or
expensive, thus per flow security verification is the logical solution.
This security is critical when priorities are used but also will greatly
improve identifying who is sending malware or creating a DoS attack.

Note also that, being assigned an available rate by the network (through
a path test via in-band signalling) ensures that TCP type flows from a
FSA signalling-capable source end system can:
 - stream at the maximum rate which is fair in the network
 - flow at much higher rates than TCP can flow today
 and for large distances greatly reduces the time to deliver a file.


5. FSA Signalling Standards Development

The direction of the standards work in the ITU is towards developing
standards that extend the range of FSA-based QoS controls through
explicit signalling with the inclusion of parameters indicating the
treatment required. The first phase of work reached consent on:

   (a)      A new transport service that provides, in effect, admission
            control in the form of the state and packet deletion actions
            associated with a flow.

   (b)      Requirements for FSA in a Next Generation Network.

Adams                     Expires March 1st, 2010               [Page 9]


Internet-Draft        FSA Signal Packet Identification    September 2009

These requirements are captured in ITU-T Recommendation Y.2121 [2]. The
ITU sent the IETF a liaison attaching Y.2121 in January 2008[3], thus
Y.2121 is available to the IETF.

The current work in the ITU is in Q5/11. Whilst many of the concepts
of (a) and (b) can be applied end-to-end, the focus of the ITU work is,
currently, only on service access scenarios.

More explicitly, the scope of the current standards initiative in the
ITU is on the application of FSA QoS in the limited capacity pathway
downstream from a service point of access towards an end system or
upstream from an end system towards a service point of access. Such a
pathway may cross through the core of an IP network, but any FSA signals
would only be visible at FSA edge functions and FSA source/ receiver
functions at either end (or both ends) of the access pathway.

FSA signals are deleted by FSA Edge functions or FSA source/ receiver
functions so that they do not travel beyond the access pathway. This
will require all FSA signal initiated at an FSA Edge (acting as the
virtual signal source) to be marked so that response signals associated
with such flows are deleted at the same Edge (even if this is separated
into different sending and receiving physical units).

Thinking further about the longer-term, there could be extensions to
what is conveyed in signalling packets to unlock new capabilities. So
far, such extensions have not been addressed, but could include:

(i)  in-band monitor on/ monitor off commands associated with
     monitoring a group of packets of a flow (or aggetegate) that trail
     behind the first such command and stop at the second such command.
(ii) in-band monitor-and-change-state-if commands associated with a
     group of packets that trail behind the first such command and
     change either a QoS state or a monitoring action if a given event
     is observed in the group of packets up until a second such command.

6. Signal Packet Identification

This internet draft is raising the solution to an issue already captured
in [2]. It is a requirement for a new type of in-band control packet to
be identifiable to any FSA node that would facilitate:

   *  The inclusion of new information obtained from (typically, but not
      necessarily) a source function, providing rate or or other
      data related to an individual flow or flow aggregate.
   *  The alerting of any of the following that new data is available:
         o  the receiving end system;
         o  downstream nodes with links that are affected by that flow;
         o  the source.

So far, Q5/11 has considered a number of alternative solutions and has
proposed a candidate solution to signal packet identification. This

Adams                     Expires March 1st, 2010              [Page 10]


Internet-Draft        FSA Signal Packet Identification    September 2009

solution is that all signal packets should be marked with DiffServ=an
EXP/LU DSCP set to "QoSSignal"

This is viewed, architecturally, in an analagous way to an "escape" key.
The DSCP = "QoSSignal" creates an escape into a new set of QoS options
that are conveyed in another part of the packet called the "QoS
Structure".

Because packets marked with an EXP/LU DSCP set to "QoSSignal" originate
and terminate on FSA Signalling Edge Functions, it is assumed that
this chosen solution does not change any internet protocol as currently
defined and operating on any network node or End-System node.

However, considering the evolution scenarios described in section 4
above, the proposed solution for FSA signal packet marking may need
further study if the scenarios of exploiting the FSA signal-enhanced
flow information and FSA QoS actions / monitoring actions extend towards
more general use between any two points on the internet.

7. Security considerations

An eavesdropper, which can monitor the packets that correspond to the
connection to be attacked could learn the IP addresses and port
numbers in use (and also sequence numbers etc.) and try to attack the
connection by generating signalling packets.

The protection of signalling packets with an authorization field is
recommended, following the principles described in [2] Annex A.

Furthermore, FSA monitoring functions may be used to determine the
frequency of signal packet arrivals and whether this frequency
exceeds some threshold that would signify an alert and a possible
DOS attack.

8. IANA considerations

This document has no actions for IANA with the existing proposal for
signal packet identification. But this would not be the case for some
alternative proposals.

9. Proposal

This internet draft indicates the background to a proposal to identify
a new in-band signalling packet and indicates the current candidate
solution that has been assumed in the ITU-T for the explicit limited
scope described above in section 5. Members of the IETF are
asked to consider this proposal and endorse the current solution for
the scope currently under consideration and determine the best solution
for extensions of this scope.



Adams                     Expires March 1st, 2010              [Page 11]


Internet-Draft        FSA Signal Packet Identification    September 2009

10. Informative References

[1]  draft-ietf-nsis-ntlp-20 (2009), GIST: General Internet Signalling
     Transport
[2]  ITU-T Recommendation Y.2121 (2008), Requirements for the support
     of flow state aware transport technology in an NGN
[3]  ITU Liaison Statement to the IETF, Jan 2008, attachment Y.2121.













































Adams                     Expires March 1st, 2010              [Page 12]

Internet-Draft        FSA Signal Packet Identification    September 2009

Authors' Address

   Dr John Adams
   CTO,
   Razoom, Inc.,
   24, Keswick Close
   Felixstowe,
   Suffolk
   IP11 9NZ

   Phone: +44 1394 272713
   email: john@razoom.com