From owner-psamp@ops.ietf.org Thu Aug 5 21:40:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02628 for ; Thu, 5 Aug 2004 21:40:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BstYf-0009ga-Tn for psamp-data@psg.com; Fri, 06 Aug 2004 01:30:09 +0000 Received: from [144.254.15.118] (helo=strange-brew.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BstYN-0009dc-5F for psamp@ops.ietf.org; Fri, 06 Aug 2004 01:29:51 +0000 Received: from [12.105.246.104] (sjc-vpn3-6.cisco.com [10.21.64.6]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i761Tmg24574 for ; Fri, 6 Aug 2004 03:29:49 +0200 (CEST) Message-ID: <4112DF0A.9080604@cisco.com> Date: Fri, 06 Aug 2004 03:29:46 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psamp Subject: Intellectual Property Statement for the sampling techniques draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, During his session, Nick Duffield mentioned that he wrote an IPR section in the sampling techniques draft, and that potentially we might need one for NetFlow. I started to investigate and this leads me to this question. The IPR statement is pretty vague, specifically if I follow the link 10. Intellectual Property Statement AT&T Corporation may own intellectual property applicable to this contribution. The IETF has been notified of AT&T's licensing intent for the specification contained in this document. See http://www.ietf.org/ietf/IPR/ATT-GENERAL.txt for AT&T's IPR statement. Should we specify exactly which method(s) AT&T has got a patent for? And what is the patent number? For example, the NetFlow IPR is pretty unambiguous. http://www.ietf.org/ietf/IPR/cisco-claise-netflow.txt Thanks for shedding some light. Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Aug 5 21:56:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03375 for ; Thu, 5 Aug 2004 21:56:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bstv2-000Cay-Rl for psamp-data@psg.com; Fri, 06 Aug 2004 01:53:16 +0000 Received: from [192.20.225.112] (helo=mail-dark.research.att.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bstus-000CZw-8z for psamp@ops.ietf.org; Fri, 06 Aug 2004 01:53:06 +0000 Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by mail-dark.research.att.com (Postfix) with ESMTP id BC1F9E80C8; Thu, 5 Aug 2004 21:53:05 -0400 (EDT) Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-green.research.att.com (Postfix) with ESMTP id AFF3CA7BAF; Thu, 5 Aug 2004 21:53:05 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: Intellectual Property Statement for the sampling techniques draft Date: Thu, 5 Aug 2004 21:53:05 -0400 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E10114F062@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: Intellectual Property Statement for the sampling techniques draft Thread-Index: AcR7VX+ftU9F1ciSSqSDtp21rnDTNgAAM1Ow From: To: , X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Benoit, There is a more recent and specific IP statement from AT&T that will be referred to in the next version of the framework draft: http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-framework.txt Concerning other assertions of IP rights, I was referring to the following psamp specific statement from Cisco, which will also be referred to in the next version: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt Nick > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Thursday, August 05, 2004 9:30 PM > To: psamp > Subject: Intellectual Property Statement for the sampling techniques draft >=20 > Hi, >=20 > During his session, Nick Duffield mentioned that he wrote an IPR section > in the sampling techniques draft, and that potentially we might need one > for NetFlow. > I started to investigate and this leads me to this question. > The IPR statement is pretty vague, specifically if I follow the link >=20 > 10. > Intellectual Property Statement >=20 > AT&T Corporation may own intellectual property applicable to > this > contribution. The IETF has been notified of AT&T's licensing > intent for the specification contained in this document. See > http://www.ietf.org/ietf/IPR/ATT-GENERAL.txt for AT&T's IPR > statement. >=20 > Should we specify exactly which method(s) AT&T has got a patent for? And > what is the patent number? > For example, the NetFlow IPR is pretty unambiguous. > http://www.ietf.org/ietf/IPR/cisco-claise-netflow.txt >=20 > Thanks for shedding some light. >=20 > Regards, Benoit. >=20 >=20 >=20 > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Aug 6 02:25:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05257 for ; Fri, 6 Aug 2004 02:25:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bsy1a-000GDh-N3 for psamp-data@psg.com; Fri, 06 Aug 2004 06:16:18 +0000 Received: from [144.254.15.118] (helo=strange-brew.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bsy1P-000GCA-QW for psamp@ops.ietf.org; Fri, 06 Aug 2004 06:16:08 +0000 Received: from [12.105.246.104] (sjc-vpn4-140.cisco.com [10.21.80.140]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i766G0g17545; Fri, 6 Aug 2004 08:16:00 +0200 (CEST) Message-ID: <4113221F.6080800@cisco.com> Date: Fri, 06 Aug 2004 08:15:59 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: duffield@research.att.com CC: psamp@ops.ietf.org Subject: Re: Intellectual Property Statement for the sampling techniques draft References: <387B5A9BF31B5D43A2B18DD9F326B8E10114F062@NJFPSRVEXG2KCL.research.att.com> In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E10114F062@NJFPSRVEXG2KCL.research.att.com> Content-Type: multipart/alternative; boundary="------------040607050604080404070307" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------040607050604080404070307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nick, >Benoit, > >There is a more recent and specific IP statement from AT&T that will be >referred to in the next version of the framework draft: > >http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-framework.txt > > This is good, as this is more specific. However, shouldn't you mention to which hashing/filtering/sampling technique(s) your IPR refers. > >Concerning other assertions of IP rights, I was referring to the >following psamp specific statement from Cisco, which will also be >referred to in the next version: > >http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt > > Very good. Regards, Benoit. > >Nick > > > > >>-----Original Message----- >>From: Benoit Claise [mailto:bclaise@cisco.com] >>Sent: Thursday, August 05, 2004 9:30 PM >>To: psamp >>Subject: Intellectual Property Statement for the sampling techniques >> >> >draft > > >>Hi, >> >>During his session, Nick Duffield mentioned that he wrote an IPR >> >> >section > > >>in the sampling techniques draft, and that potentially we might need >> >> >one > > >>for NetFlow. >>I started to investigate and this leads me to this question. >>The IPR statement is pretty vague, specifically if I follow the link >> >> 10. >> Intellectual Property Statement >> >> AT&T Corporation may own intellectual property applicable to >> this >> contribution. The IETF has been notified of AT&T's licensing >> intent for the specification contained in this document. See >> http://www.ietf.org/ietf/IPR/ATT-GENERAL.txt for AT&T's IPR >> statement. >> >>Should we specify exactly which method(s) AT&T has got a patent for? >> >> >And > > >>what is the patent number? >>For example, the NetFlow IPR is pretty unambiguous. >>http://www.ietf.org/ietf/IPR/cisco-claise-netflow.txt >> >>Thanks for shedding some light. >> >>Regards, Benoit. >> >> >> >>-- >>to unsubscribe send a message to psamp-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> >> > > > --------------040607050604080404070307 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nick, 
Benoit,

There is a more recent and specific IP statement from AT&T that will be
referred to in the next version of the framework draft:

http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-framework.txt
This is good, as this is more specific.
However, shouldn't you mention to which hashing/filtering/sampling technique(s) your IPR refers.

Concerning other assertions of IP rights, I was referring to the
following psamp specific statement from Cisco, which will also be
referred to in the next version:

http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt
Very good.

Regards, Benoit.


Nick


  
-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, August 05, 2004 9:30 PM
To: psamp
Subject: Intellectual Property Statement for the sampling techniques
    
draft
  
Hi,

During his session, Nick Duffield mentioned that he wrote an IPR
    
section
  
in the sampling techniques draft, and that potentially we might need
    
one
  
for NetFlow.
I started to investigate and this leads me to this question.
The IPR statement is pretty vague, specifically if I follow the link

  10.
      Intellectual Property Statement

     AT&T Corporation may own intellectual property applicable to
     this
     contribution. The IETF has been notified of AT&T's licensing
     intent for the specification contained in this document. See
     http://www.ietf.org/ietf/IPR/ATT-GENERAL.txt for AT&T's IPR
     statement.

Should we specify exactly which method(s) AT&T has got a patent for?
    
And
  
what is the patent number?
For example, the NetFlow IPR is pretty unambiguous.
http://www.ietf.org/ietf/IPR/cisco-claise-netflow.txt

Thanks for shedding some light.

Regards, Benoit.



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

--------------040607050604080404070307-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Tue Aug 10 10:36:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01069 for ; Tue, 10 Aug 2004 10:36:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuXWp-0008Xg-VM for psamp-data@psg.com; Tue, 10 Aug 2004 14:23:03 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuXWe-0008Uq-Ga for psamp@ops.ietf.org; Tue, 10 Aug 2004 14:22:52 +0000 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mail-white.research.att.com (Postfix) with ESMTP id E9DFD664089; Tue, 10 Aug 2004 10:22:51 -0400 (EDT) Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-blue.research.att.com (Postfix) with ESMTP id DDE4E1974C6; Tue, 10 Aug 2004 10:19:52 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: Intellectual Property Statement for the sampling techniques draft MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47EE5.8849360F" Date: Tue, 10 Aug 2004 10:22:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E18BF0D8@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: Intellectual Property Statement for the sampling techniques draft Thread-Index: AcR7fNycQptYSRQnQuqA7gw6M4lITADaJddg From: To: Cc: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C47EE5.8849360F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Benoit, =20 The AT&T disclosure conforms to the requirements of RFC 3668; additional information is not required. =20 Nick =20 =20 _____ =20 From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Friday, August 06, 2004 2:16 AM To: Duffield,Nicholas G (Nick) Cc: psamp@ops.ietf.org Subject: Re: Intellectual Property Statement for the sampling techniques draft =20 Nick,=20 Benoit, =20 There is a more recent and specific IP statement from AT&T that will be referred to in the next version of the framework draft: =20 http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-framework.txt =20 This is good, as this is more specific. However, shouldn't you mention to which hashing/filtering/sampling technique(s) your IPR refers. =20 =20 Concerning other assertions of IP rights, I was referring to the following psamp specific statement from Cisco, which will also be referred to in the next version: =20 http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt =20 Very good. Regards, Benoit. =20 =20 Nick =20 =20 =20 -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Thursday, August 05, 2004 9:30 PM To: psamp Subject: Intellectual Property Statement for the sampling techniques =20 draft =20 Hi, =20 During his session, Nick Duffield mentioned that he wrote an IPR =20 section =20 in the sampling techniques draft, and that potentially we might need =20 one =20 for NetFlow. I started to investigate and this leads me to this question. The IPR statement is pretty vague, specifically if I follow the link =20 10. Intellectual Property Statement =20 AT&T Corporation may own intellectual property applicable to this contribution. The IETF has been notified of AT&T's licensing intent for the specification contained in this document. See http://www.ietf.org/ietf/IPR/ATT-GENERAL.txt for AT&T's IPR statement. =20 Should we specify exactly which method(s) AT&T has got a patent for? =20 And =20 what is the patent number? For example, the NetFlow IPR is pretty unambiguous. http://www.ietf.org/ietf/IPR/cisco-claise-netflow.txt =20 Thanks for shedding some light. =20 Regards, Benoit. =20 =20 =20 -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: =20 =20 =20 =20 =20 ------_=_NextPart_001_01C47EE5.8849360F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Benoit,

 

The AT&T disclosure conforms to the requirements of RFC = 3668; additional information is not required.

 

Nick

 

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Friday, August 06, = 2004 2:16 AM
To: Duffield,Nicholas G = (Nick)
Cc: = psamp@ops.ietf.org
Subject: Re: Intellectual = Property Statement for the sampling techniques draft

 

Nick, 

Benoit,
 
There is a more recent and specific IP =
statement from AT&T that will =
be
referred to in the next version of the =
framework draft:
 
http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-framework.txt
 

This is good, as this is more specific.
However, shouldn't you mention to which hashing/filtering/sampling = technique(s) your IPR refers.

 
 
Concerning other assertions of IP rights, I =
was referring to the
following psamp specific statement from =
Cisco, which will also be
referred to in the next =
version:
 
http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt=

 

Very good.

Regards, Benoit.


 
 
Nick
 
 
  
-----Original =
Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, August 05, 2004 9:30 =
PM
To: =
psamp
Subject: Intellectual Property Statement for =
the sampling techniques
    =

draft
  
Hi,
 
During his session, Nick Duffield mentioned =
that he wrote an IPR
    =

section
  
in the sampling techniques draft, and that =
potentially we might need
    =

one
  
for =
NetFlow.
I started to investigate and this leads me to =
this question.
The IPR statement is pretty vague, =
specifically if I follow the =
link
 
  =
10.
      Intellectual =
Property Statement
 
     AT&T Corporation =
may own intellectual property applicable =
to
     =
this
     contribution. The =
IETF has been notified of AT&T's =
licensing
     intent for the =
specification contained in this document. =
See
     http://www.ietf.org=
/ietf/IPR/ATT-GENERAL.txt for AT&T's =
IPR
     =
statement.
 
Should we specify exactly which method(s) =
AT&T has got a patent for?
    =

And
  
what is the patent =
number?
For example, the NetFlow IPR is pretty =
unambiguous.
http://www=
.ietf.org/ietf/IPR/cisco-claise-netflow.txt<=
/pre>
 
Thanks for shedding some =
light.
 
Regards, =
Benoit.
 
 
 
--
to unsubscribe send a message to psamp-request@ops.ietf.org=
 with
the word 'unsubscribe' in a single line as =
the message text body.
archive: <http://ops.ietf.org/lists/p=
samp/>
    =

 
 

 

------_=_NextPart_001_01C47EE5.8849360F-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Aug 12 08:54:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28945 for ; Thu, 12 Aug 2004 08:54:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvEva-0007e9-1y for psamp-data@psg.com; Thu, 12 Aug 2004 12:43:30 +0000 Received: from [144.254.15.118] (helo=strange-brew.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvEvO-0007dB-P2 for psamp@ops.ietf.org; Thu, 12 Aug 2004 12:43:19 +0000 Received: from [192.168.0.3] (ams-clip-vpn-dhcp39.cisco.com [10.61.64.39]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i7CChEg02246; Thu, 12 Aug 2004 14:43:14 +0200 (CEST) Message-ID: <411B65E1.4070606@cisco.com> Date: Thu, 12 Aug 2004 14:43:13 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: duffield@research.att.com CC: psamp@ops.ietf.org Subject: Re: Intellectual Property Statement for the sampling techniques draft References: <387B5A9BF31B5D43A2B18DD9F326B8E18BF0D8@NJFPSRVEXG2KCL.research.att.com> In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E18BF0D8@NJFPSRVEXG2KCL.research.att.com> Content-Type: multipart/alternative; boundary="------------050201000904070409090201" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------050201000904070409090201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Nick, I'm not a lawyer! And I'm happy not to be one. ;) However, I had to read RFC3667/3668 for the NetFlow IPR. And I think the draft doesn't comply to it. First of all, you must insert something like in the draft status 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 RFC 3668. Second, I think your statement in the draft violates the rule on blanket statements in RFC3668 6.4.3. The requirement for an IPR disclosure is not satisfied by the submission of a blanket statement of possible IPR on every Contribution. This is the case because the aim of the disclosure requirement is to provide information about specific IPR against specific technology under discussion in the IETF. The requirement is also not satisfied by a blanket statement of willingness to license all potential IPR under fair and non-discriminatory terms for the same reason. However, the requirement for an IPR disclosure is satisfied by a blanket statement of the IPR discloser's willingness to license all of its potential IPR meeting the requirements of Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers of an IETF specification on a royalty-free basis as long as any other terms and conditions are disclosed in the IPR disclosure statement. Regards, Benoit-not-a-lawyer > Benoit, > > > > The AT&T disclosure conforms to the requirements of RFC 3668; > additional information is not required. > > > > Nick > > > > > > ------------------------------------------------------------------------ > > *From:* Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Friday, August 06, 2004 2:16 AM > *To:* Duffield,Nicholas G (Nick) > *Cc:* psamp@ops.ietf.org > *Subject:* Re: Intellectual Property Statement for the sampling > techniques draft > > > > Nick, > >Benoit, > > > >There is a more recent and specific IP statement from AT&T that will be > >referred to in the next version of the framework draft: > > > >http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-framework.txt > > > > This is good, as this is more specific. > However, shouldn't you mention to which hashing/filtering/sampling > technique(s) your IPR refers. > > > > > >Concerning other assertions of IP rights, I was referring to the > >following psamp specific statement from Cisco, which will also be > >referred to in the next version: > > > >http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt > > > > Very good. > > Regards, Benoit. > > > > > > >Nick > > > > > > > >>-----Original Message----- >> >>From: Benoit Claise [mailto:bclaise@cisco.com] >> >>Sent: Thursday, August 05, 2004 9:30 PM >> >>To: psamp >> >>Subject: Intellectual Property Statement for the sampling techniques >> >> >> >draft > > > >>Hi, >> >> >> >>During his session, Nick Duffield mentioned that he wrote an IPR >> >> >> >section > > > >>in the sampling techniques draft, and that potentially we might need >> >> >> >one > > > >>for NetFlow. >> >>I started to investigate and this leads me to this question. >> >>The IPR statement is pretty vague, specifically if I follow the link >> >> >> >> 10. >> >> Intellectual Property Statement >> >> >> >> AT&T Corporation may own intellectual property applicable to >> >> this >> >> contribution. The IETF has been notified of AT&T's licensing >> >> intent for the specification contained in this document. See >> >> http://www.ietf.org/ietf/IPR/ATT-GENERAL.txt for AT&T's IPR >> >> statement. >> >> >> >>Should we specify exactly which method(s) AT&T has got a patent for? >> >> >> >And > > > >>what is the patent number? >> >>For example, the NetFlow IPR is pretty unambiguous. >> >>http://www.ietf.org/ietf/IPR/cisco-claise-netflow.txt >> >> >> >>Thanks for shedding some light. >> >> >> >>Regards, Benoit. >> >> >> >> >> >> >> >>-- >> >>to unsubscribe send a message to psamp-request@ops.ietf.org with >> >>the word 'unsubscribe' in a single line as the message text body. >> >>archive: >> >> >> > > > > > > --------------050201000904070409090201 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Nick,

I'm not a lawyer! And I'm happy not to be one. ;)

However, I had to read RFC3667/3668 for the NetFlow IPR.
And I think the draft doesn't comply to it.

First of all, you must insert something like in the draft status
   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 RFC 3668.
Second, I think your statement in the draft violates the rule on blanket statements in RFC3668
6.4.3.  The requirement for an IPR disclosure is not satisfied by the
   submission of a blanket statement of possible IPR on every
   Contribution.  This is the case because the aim of the disclosure
   requirement is to provide information about specific IPR against
   specific technology under discussion in the IETF.  The requirement is
   also not satisfied by a blanket statement of willingness to license
   all potential IPR under fair and non-discriminatory terms for the
   same reason.  However, the requirement for an IPR disclosure is
   satisfied by a blanket statement of the IPR discloser's willingness
   to license all of its potential IPR meeting the requirements of
   Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers of an
   IETF specification on a royalty-free basis as long as any other terms
   and conditions are disclosed in the IPR disclosure statement.  
Regards, Benoit-not-a-lawyer

Benoit,

 

The AT&T disclosure conforms to the requirements of RFC 3668; additional information is not required.

 

Nick

 

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Friday, August 06, 2004 2:16 AM
To: Duffield,Nicholas G (Nick)
Cc: psamp@ops.ietf.org
Subject: Re: Intellectual Property Statement for the sampling techniques draft

 

Nick, 

Benoit,
 
There is a more recent and specific IP statement from AT&T that will be
referred to in the next version of the framework draft:
 
http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-framework.txt
 

This is good, as this is more specific.
However, shouldn't you mention to which hashing/filtering/sampling technique(s) your IPR refers.

 
 
Concerning other assertions of IP rights, I was referring to the
following psamp specific statement from Cisco, which will also be
referred to in the next version:
 
http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt
 

Very good.

Regards, Benoit.


 
 
Nick
 
 
  
-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, August 05, 2004 9:30 PM
To: psamp
Subject: Intellectual Property Statement for the sampling techniques
    
draft
  
Hi,
 
During his session, Nick Duffield mentioned that he wrote an IPR
    
section
  
in the sampling techniques draft, and that potentially we might need
    
one
  
for NetFlow.
I started to investigate and this leads me to this question.
The IPR statement is pretty vague, specifically if I follow the link
 
  10.
      Intellectual Property Statement
 
     AT&T Corporation may own intellectual property applicable to
     this
     contribution. The IETF has been notified of AT&T's licensing
     intent for the specification contained in this document. See
     http://www.ietf.org/ietf/IPR/ATT-GENERAL.txt for AT&T's IPR
     statement.
 
Should we specify exactly which method(s) AT&T has got a patent for?
    
And
  
what is the patent number?
For example, the NetFlow IPR is pretty unambiguous.
http://www.ietf.org/ietf/IPR/cisco-claise-netflow.txt
 
Thanks for shedding some light.
 
Regards, Benoit.
 
 
 
--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>
    
 
 

 


--------------050201000904070409090201-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Aug 16 12:19:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13654 for ; Mon, 16 Aug 2004 12:19:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwk38-0003Xk-Je for psamp-data@psg.com; Mon, 16 Aug 2004 16:09:30 +0000 Received: from [192.20.225.112] (helo=mail-yellow.research.att.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bwk2x-0003Wk-Th for psamp@ops.ietf.org; Mon, 16 Aug 2004 16:09:20 +0000 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 926451974DF; Mon, 16 Aug 2004 12:05:53 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: Intellectual Property Statement for the sampling techniques draft Date: Mon, 16 Aug 2004 12:09:24 -0400 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E10114F618@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: Intellectual Property Statement for the sampling techniques draft Thread-Index: AcSAafT5LkaLZmwpQS6M1sV2lZi7bADQApMA From: To: Cc: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Benoit, ________________________________________ > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Thursday, August 12, 2004 8:43 AM > To: Duffield,Nicholas G (Nick) > Cc: psamp@ops.ietf.org > Subject: Re: Intellectual Property Statement for the sampling=20 > techniques draft >=20 > Hi Nick, >=20 > I'm not a lawyer! And I'm happy not to be one. ;) >=20 > However, I had to read RFC3667/3668 for the NetFlow IPR. > And I think the draft doesn't comply to it. >=20 > First of all, you must insert something like in the draft status > =A0=A0 By submitting this Internet-Draft, each author represents that = any > =A0=A0 applicable patent or other IPR claims of which he or she is = aware > =A0=A0 have been or will be disclosed, and any of which he or she = becomes > =A0=A0 aware will be disclosed, in accordance with Section 6 of RFC = 3668. This text will be included, as required in RFC 3667. Thanks > Second, I think your statement in the draft violates the rule on=20 > blanket statements in RFC3668 6.4.3.=A0 The requirement for an IPR=20 > disclosure is not satisfied by the > =A0=A0 submission of a blanket statement of possible IPR on every > =A0=A0 Contribution.=A0 This is the case because the aim of the = disclosure > =A0=A0 requirement is to provide information about specific IPR = against > =A0=A0 specific technology under discussion in the IETF.=A0 The = requirement=20 > is > =A0=A0 also not satisfied by a blanket statement of willingness to = license > =A0=A0 all potential IPR under fair and non-discriminatory terms for = the > =A0=A0 same reason.=A0 However, the requirement for an IPR disclosure = is > =A0=A0 satisfied by a blanket statement of the IPR discloser's = willingness > =A0=A0 to license all of its potential IPR meeting the requirements of > =A0=A0 Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers = of=20 > an > =A0=A0 IETF specification on a royalty-free basis as long as any other = > terms > =A0=A0 and conditions are disclosed in the IPR disclosure statement. > Regards, Benoit-not-a-lawyer > Benoit, >=20 I think the term "blanket statements" refers here to the generic IP = statements such as those found near the top of = http://www.ietf.org/ipr.html. The statement referred to in previous = versions of this draft was of this type. The new AT&T statement, = however, conforms to RFC 3668, and in particular, Section 6.4.1. Here is the proposed new IPR section for the framework draft.=20 16. Intellectual Property Statements 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 RFC 3668. The IETF has been notified by AT&T Corp. of intellectual property rights = claimed in regard to some or all of the specification contained in this = document. For more information, see=20 http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-framework.txt The IETF has been notified by Cisco Corp. of intellectual property = rights claimed in regard to some or all of the specification contained = in this document. For more information, see=20 http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt Nick > The AT&T disclosure conforms to the requirements of RFC 3668;=20 > additional information is not required. >=20 > Nick >=20 >=20 > ________________________________________ > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Friday, August 06, 2004 2:16 AM > To: Duffield,Nicholas G (Nick) > Cc: psamp@ops.ietf.org > Subject: Re: Intellectual Property Statement for the sampling=20 > techniques draft >=20 > Nick, >=20 >=20 > Benoit, >=20 > There is a more recent and specific IP statement from AT&T that will=20 > be referred to in the next version of the framework draft: >=20 > http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-framework.txt >=20 > This is good, as this is more specific. > However, shouldn't you mention to which hashing/filtering/sampling > technique(s) your IPR refers. >=20 >=20 >=20 >=20 > Concerning other assertions of IP rights, I was referring to the=20 > following psamp specific statement from Cisco, which will also be=20 > referred to in the next version: >=20 > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt >=20 > Very good. >=20 > Regards, Benoit. >=20 >=20 >=20 >=20 >=20 > Nick >=20 >=20 >=20 > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Thursday, August 05, 2004 9:30 PM > To: psamp > Subject: Intellectual Property Statement for the sampling techniques >=20 > draft >=20 > Hi, >=20 > During his session, Nick Duffield mentioned that he wrote an IPR >=20 > section >=20 > in the sampling techniques draft, and that potentially we might need >=20 > one >=20 > for NetFlow. > I started to investigate and this leads me to this question. > The IPR statement is pretty vague, specifically if I follow the link >=20 > =A0 10. > =A0=A0 =A0=A0=A0Intellectual Property Statement >=20 > =A0=A0=A0=A0 AT&T Corporation may own intellectual property applicable = to > =A0=A0=A0=A0 this > =A0=A0=A0=A0 contribution. The IETF has been notified of AT&T's = licensing > =A0=A0=A0=A0 intent for the specification contained in this document. = See > =A0=A0=A0=A0 http://www.ietf.org/ietf/IPR/ATT-GENERAL.txt for AT&T's = IPR > =A0=A0=A0=A0 statement. >=20 > Should we specify exactly which method(s) AT&T has got a patent for? >=20 > And >=20 > what is the patent number? > For example, the NetFlow IPR is pretty unambiguous. > http://www.ietf.org/ietf/IPR/cisco-claise-netflow.txt >=20 > Thanks for shedding some light. >=20 > Regards, Benoit. >=20 >=20 >=20 > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with the=20 > word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 >=20 >=20 -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Aug 18 15:37:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01958 for ; Wed, 18 Aug 2004 15:37:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxW6F-000KX7-Pe for psamp-data@psg.com; Wed, 18 Aug 2004 19:27:55 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxW64-000KUc-U3 for psamp@ops.ietf.org; Wed, 18 Aug 2004 19:27:45 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01573; Wed, 18 Aug 2004 15:26:42 -0400 (EDT) Message-Id: <200408181926.PAA01573@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: psamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-psamp-framework-07.txt Date: Wed, 18 Aug 2004 15:26:41 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Packet Sampling Working Group of the IETF. Title : A Framework for Passive Packet Measurement Author(s) : N. Duffield Filename : draft-ietf-psamp-framework-07.txt Pages : 32 Date : 2004-8-18 This document specifies a framework for the PSAMP (Packet Sampling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized reports, form a stream of reports on the selected packets, and to export that stream to a collector. This framework details the components of this architecture, then describes some generic requirements, motivated the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting and export are described, along with configuration of the PSAMP functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-psamp-framework-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-psamp-framework-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-18143155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-psamp-framework-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-psamp-framework-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-18143155.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Aug 19 05:10:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14348 for ; Thu, 19 Aug 2004 05:10:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxip3-000Opn-UY for psamp-data@psg.com; Thu, 19 Aug 2004 09:03:01 +0000 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxinq-000OZC-70 for psamp@ops.ietf.org; Thu, 19 Aug 2004 09:01:46 +0000 Received: from [10.1.1.171] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 1D2F01BAC4D for ; Thu, 19 Aug 2004 11:01:42 +0200 (CEST) Date: Thu, 19 Aug 2004 11:01:53 +0200 From: Juergen Quittek To: psamp@ops.ietf.org Subject: WG last call on PSAMP framwork until Sep 28 Message-ID: <2147483647.1092913313@[10.1.1.171]> In-Reply-To: <200408181926.PAA01573@ietf.org> References: <200408181926.PAA01573@ietf.org> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, Nick has submitted a new version of the PSAMP framework document draft-ietf-psamp-framework-07.txt. There already was a WG last call before the San Diego meeting and Nick received comments and improved the document. Compared to the previous version, the changes applied are rather small. Nick, can you please post a list of the changes? Now we start a brief second WG last call on this document lasting one week only. This WG last call on draft-ietf-psamp-framework-07.txt will end on Friday September 28, 2004. Please let's all have another look at the document and particularly at the applied changes. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 18.08.2004 15:26 h -0400 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Packet Sampling Working Group of the IETF. > > Title : A Framework for Passive Packet Measurement > Author(s) : N. Duffield > Filename : draft-ietf-psamp-framework-07.txt > Pages : 32 > Date : 2004-8-18 > > This document specifies a framework for the PSAMP (Packet > Sampling) protocol. The functions of this protocol are to select > packets from a stream according to a set of standardized reports, > form a stream of reports on the selected packets, and to export > that stream to a collector. This framework details the components > of this architecture, then describes some generic requirements, > motivated the dual aims of ubiquitous deployment and utility of > the reports for applications. Detailed requirements for > selection, reporting and export are described, along with > configuration of the PSAMP functions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-07.txt > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Aug 19 14:01:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20304 for ; Thu, 19 Aug 2004 14:01:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxr10-000KD2-PM for psamp-data@psg.com; Thu, 19 Aug 2004 17:47:54 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxr0q-000KC7-0A for psamp@ops.ietf.org; Thu, 19 Aug 2004 17:47:44 +0000 Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243]) by mail-green.research.att.com (Postfix) with ESMTP id 6FD89A7BBE; Thu, 19 Aug 2004 13:47:43 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: WG last call on PSAMP framwork until Sep 28 Date: Thu, 19 Aug 2004 13:47:25 -0400 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E19153C6@NJFPSRVEXG2KCL.research.att.com> Thread-Topic: WG last call on PSAMP framwork until Sep 28 Thread-Index: AcSFy2/vyOyeY0j0RzenyEYNfQEzZwASDKKg From: To: , X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > Sent: Thursday, August 19, 2004 5:02 AM > To: psamp@ops.ietf.org > Subject: WG last call on PSAMP framwork until Sep 28 [..] > Nick, can you please post a list of the changes? >=20 Changes version 05 -> 06=20 o Framework draft is informational Other drafts will become PSAMP normative references o Language issues "must", "should", and "may", for guidance o Abstract Rewritten to reflect changes in document o Section 1. Added PSAMP documents overview o Section 3.1 Added PSAMP architecture overview o Section 3.2-3.7 Terminology Terminology broken out by selection/reporting/export process Ordering not alphabetic, but forward dependencies now removed o Section 3.3. Selection State Selection state is post processing of packets o Section 3.4 Packet Reports Definition explicitly includes selection state o Section 3.7. PSAMP Device Definition added (Similar to IPFIX device) o Section 3.10 Added description/pointer on interaction with IPFIX o Section 4. Generic requirements Emphasize generic nature of requirements o Section 4.1. Generic selection requirements Minor tweaking of "extensibility", "flexibility" and "parallel measurement process"=20 Encrypted packets: can be ignored when detected, detection mechanisms left unspecified o Section 4.2 Generic reporting requirements Minor tweaking of "self-defining" and "accuracy" "Transparency" retermed as "indication of information loss"=20 o Section 5. Packet selection operations o Section 5.1. Terminology Normative reference will be [PSAMP-TECH] Include only terms used in framework. o Section 5.2. Selection Operations Retained high level descriptions of selection operation Removed material from old Section 4.2 on hashing applications (it will appear in [PSAMP-TECH]) O Section 5.3. Input Sequence Numbers In a composite selector, report input sequence numbers for each component selector o Removed old Section 4.6 on criteria for choice of selectors Organizational Changes (4) o Section 6. Reporting Process Question arose: whether to use IPFIX terminology Resolution: retain PSAMP terminology (Better to have clean and consistent set of definitions, IPFIX still in flux) o Sections 6.1. and 6.2 Clarification that Basic Reporting (i.e. first N bytes of packets) is mandatory to support but optional to use. May want to use extended reporting instead, if supported. o Section 8. Export Process o Section 8.1. Reflect choice of IPFIX for export IPFIX must support STCP-PR: congestion avoiding unreliable transport=20 Substantial reorganization Omit old Section 7.7 on collector based rate reconfiguration o Section 13. Normative References Placeholders for other PSAMP documents Consequence: submission as RFC must wait till other docs complete Changes version 06 -> 07 o New Section 5.3 on Selection Rate Terminology. (Restored terms needed in Section 5.4)=20 o Section 11. Applications Rework to bring out unique advantages of PSAMP o Section 13. Intellectual Property Statements Added boilerplate from RFC 3667 Update to reflect recent IP statement by AT&T to IETF =09 http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-framework.txt Add reference to Cisco's assertion of IP to IETF =09 http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Aug 19 19:16:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18139 for ; Thu, 19 Aug 2004 19:16:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxw1z-000GWd-FC for psamp-data@psg.com; Thu, 19 Aug 2004 23:09:15 +0000 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxw1o-000GTy-By for psamp@ops.ietf.org; Thu, 19 Aug 2004 23:09:04 +0000 Received: from dialin-145-254-223-023.arcor-ip.net (dialin-145-254-223-023.arcor-ip.net [145.254.223.23]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 7030F1BAC4D for ; Fri, 20 Aug 2004 01:08:55 +0200 (CEST) Date: Fri, 20 Aug 2004 01:09:07 +0200 From: Juergen Quittek To: psamp@ops.ietf.org Subject: Re: WG last call on PSAMP framwork until AUG!!! 28 Message-ID: <2147483647.1092964146@dialin-145-254-223-023.arcor-ip.net> In-Reply-To: <2147483647.1092913313@[10.1.1.171]> References: <200408181926.PAA01573@ietf.org> <2147483647.1092913313@[10.1.1.171]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,PLING_PLING autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I made a mistake. Intended was a BRIEF last call. It will end on AUGUST 28, not on September 28. The 28th of August is Friday next next week. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 19.08.2004 11:01 Uhr +0200 Juergen Quittek wrote: > Dear all, > > Nick has submitted a new version of the PSAMP framework document > draft-ietf-psamp-framework-07.txt. > > There already was a WG last call before the San Diego meeting > and Nick received comments and improved the document. Compared to > the previous version, the changes applied are rather small. > > Nick, can you please post a list of the changes? > > Now we start a brief second WG last call on this document lasting > one week only. > > This WG last call on draft-ietf-psamp-framework-07.txt > will end on Friday September 28, 2004. > > Please let's all have another look at the document > and particularly at the applied changes. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > > > --On 18.08.2004 15:26 h -0400 Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Packet Sampling Working Group of the IETF. >> >> Title : A Framework for Passive Packet Measurement >> Author(s) : N. Duffield >> Filename : draft-ietf-psamp-framework-07.txt >> Pages : 32 >> Date : 2004-8-18 >> >> This document specifies a framework for the PSAMP (Packet >> Sampling) protocol. The functions of this protocol are to select >> packets from a stream according to a set of standardized reports, >> form a stream of reports on the selected packets, and to export >> that stream to a collector. This framework details the components >> of this architecture, then describes some generic requirements, >> motivated the dual aims of ubiquitous deployment and utility of >> the reports for applications. Detailed requirements for >> selection, reporting and export are described, along with >> configuration of the PSAMP functions. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-07.txt >> > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Aug 30 08:26:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18379 for ; Mon, 30 Aug 2004 08:26:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1l72-0004TR-1h for psamp-data@psg.com; Mon, 30 Aug 2004 12:18:16 +0000 Received: from [144.254.15.118] (helo=strange-brew.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1l6r-0004SA-4b for psamp@ops.ietf.org; Mon, 30 Aug 2004 12:18:05 +0000 Received: from [192.168.0.4] (ams-clip-vpn-dhcp4385.cisco.com [10.61.81.32]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i7UCI1g03116; Mon, 30 Aug 2004 14:18:03 +0200 (CEST) Message-ID: <41331AF9.8000802@cisco.com> Date: Mon, 30 Aug 2004 14:18:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psamp CC: Henrik Levkowetz Subject: http://ietf.levkowetz.com/drafts/psamp/ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, Thanks to Henrik Levkowetz , we now have posted the complete set of differences between draft versions. This automatic process (updated every 6 hours) might help to speed up the review process... no need to always review the entire new draft. Regards, Benoit. -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Mon Aug 30 18:51:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11475 for ; Mon, 30 Aug 2004 18:51:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1ug6-000OWS-61 for psamp-data@psg.com; Mon, 30 Aug 2004 22:31:06 +0000 Received: from [144.254.15.118] (helo=strange-brew.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1ufq-000OVH-UH for psamp@ops.ietf.org; Mon, 30 Aug 2004 22:30:51 +0000 Received: from [192.168.0.4] (ams-clip-vpn-dhcp4385.cisco.com [10.61.81.32]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i7UMUbg06599; Tue, 31 Aug 2004 00:30:37 +0200 (CEST) Message-ID: <4133AA8C.1000401@cisco.com> Date: Tue, 31 Aug 2004 00:30:36 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psamp Subject: Last-Call: comments on draft-ietf-psamp-framework-07.txt + draft-ietf-psamp-framework-08.txt Content-Type: multipart/mixed; boundary="------------020900030702040403060700" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,HTML_FONTCOLOR_UNKNOWN, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.64 Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------020900030702040403060700 Content-Type: multipart/alternative; boundary="------------050207090903090605030906" --------------050207090903090605030906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, The draft improved a lot compared to version 05. Thanks Nick. First of all, I spent a few hours over the phone today with Nick correcting a some typo/improving some sentences/moving around some paragraphs/changing minor things. However, as the list is quite long, it's simply more efficient to post a new draft with the new version. As we are at the last-call deadline, I'm exceptionally posting the draft to the mailing list along with a html file with the "diff", in order to speed up the review process. While waiting for the draft 08 to be posted, you can read the attached version. Below are a few points that still need to be addressed in this version 8. 1. Once defined in the terminology section, the definitions should have upper cases 2. An new CISCO IPR statement for this draft has been sent to the IETF. We're still waiting for it to appear at http://www.ietf.org/ipr.html Once published, the URL "http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt" in section 16 should be updated. 3. As we deal with an informational RFC, so no MAY, SHOULD, MUST, I think that we should remove the next paragraph. 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. Can someone confirm? 4. Somewhere in section 3.3, I would add (for the sake of clarity) a diagram with the notions of - primitive selector versus composite selector - observed packet stream versus packet - generic case of a primitive selector, where the measurement process input is the observed packet stream - exception case of a composite selector: Generic case: +----------+ +---------+ +---------+ |Selection | | | | | Observed |Process | |Reporting| |Exporting| Packet--->|(primitive|--->|Process |--->|Process |--->Collector Stream | selector)| | | | | +----------+ +---------+ +---------+ \----Measurement Process-----/ Exception case: +----------+ +----------+ +---------+ +---------+ |Selection | |Selection | | | | | Observed |Process | |Process | |Reporting| |Exporting| Packet--->|(primitive|- Packet ->|(primitive|--->|Process |--->|Process |--->Collector Stream |selector1)| Stream |selector2)| | | | | +----------+ +----------+ +---------+ +---------+ \---------Composite Selector--------/ \----------------Measurement Process----------------/ If we create this generic case and this exception case, we could simplify (actually reuse the terminology) 2 definitions: Selection Process" and "Attained Selection Frequency" (section 5.3) * Selection Process A selection process takes a _Observed _Packet Stream as its input and selects a subset of that stream as its output. * Attained Selection Frequency: the actual frequency with which packets are selected by a selection process. When packets are selected from the _Observed Packet Stream_, the attained sampling frequency is calculated as ratio of the number of packets selected to the number of packets in _the Observed Packet Stream_. 5. The section "3.10 PSAMP and IPFIX Interaction" only discusses the PSAMP measurement process versus the IPFIX metering process aspect. There are many other aspects, as discussed in section 4 of [PSAMP-PROTO] 4. Differences between PSAMP and IPFIX..........................4 4.1 Architecture Point of View.................................4 4.2 Protocol Point of View.....................................6 4.3 Information Model Point of View............................6 We have 2 solutions: 1. we cover all the differences also in this section 2. we refer to the [PSAMP-PROTO] in this draft I guess that the solution 2 is better. 6. Section 5.2, under "Router State Filtering". We know that the filtering definition says: Filtering: a filter is a selection operation that selects a packet deterministically based on the packet content, its treatment, and functions of these occurring in the selection state. We must add a note that the "Router State Filtering" only deals with the packet treatment part of the definition. 7. The Trajectory Sampling definition in section 11.2 Trajectory sampling is the selection of a subset of packets at either all of a set of observation points or none of them. I think the "none of them" part of the definition is confusing. I would write something like Trajectory sampling is the selection of a subset of packets at either all of a specific Observation Points in the network (for example, all ingress interface). Regards, Benoit. --------------050207090903090605030906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Dear all,


The draft improved a lot compared to version 05. Thanks Nick.

First of all, I spent a few hours over the phone today with Nick correcting a some typo/improving some sentences/moving around some paragraphs/changing minor things. However, as the list is quite long, it's simply more efficient to post a new draft with the new version. As we are at the last-call deadline, I'm exceptionally posting the draft to the mailing list along with a html file with the "diff", in order to speed up the review process. While waiting for the draft 08 to be posted, you can read the attached version.

Below are a few points that still need to be addressed in this version 8.

1. Once defined in the terminology section, the definitions should have upper cases

2. An new CISCO IPR statement for this draft has been sent to the IETF.
We're still waiting for it to appear at http://www.ietf.org/ipr.html
Once published, the URL "http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-protocol.txt" in section 16 should be updated.

3.  As we deal with an informational RFC, so no MAY, SHOULD, MUST, I think that we should remove the next paragraph.
      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. 
Can someone confirm?
4. Somewhere in section 3.3, I would add (for the sake of clarity) a diagram with the notions of
- primitive selector versus composite selector
- observed packet stream versus packet
- generic case of a  primitive selector, where the measurement process input is the observed packet stream
- exception case of a composite selector:

Generic case: 
          +----------+    +---------+    +---------+ 
          |Selection |    |         |    |         | 
Observed  |Process   |    |Reporting|    |Exporting|
Packet--->|(primitive|--->|Process  |--->|Process  |--->Collector 
Stream    | selector)|    |         |    |         |  
          +----------+    +---------+    +---------+  
         \----Measurement Process-----/  

Exception case: 
           +----------+           +----------+    +---------+    +---------+ 
           |Selection |           |Selection |    |         |    |         |
 Observed  |Process   |           |Process   |    |Reporting|    |Exporting| 
 Packet--->|(primitive|- Packet ->|(primitive|--->|Process  |--->|Process  |--->Collector   
 Stream    |selector1)|  Stream   |selector2)|    |         |    |         |   
           +----------+           +----------+    +---------+    +---------+ 
           \---------Composite Selector--------/   
           \----------------Measurement Process----------------/

If we create this generic case and this exception case, we could simplify (actually reuse the terminology) 2 definitions: Selection Process" and "Attained Selection Frequency" (section 5.3) 
      * Selection Process 
         
        A selection process takes a Observed Packet Stream as its input and 
        selects a subset of that stream as its output. 

      * Attained Selection Frequency: the actual frequency with which 
        packets are selected by a selection process. When packets are 
        selected from the Observed Packet Stream, the attained 
        sampling frequency is calculated as ratio of the number of 
        packets selected to the number of packets in the Observed Packet
        Stream.


5. The section "3.10 PSAMP and IPFIX Interaction" only discusses the PSAMP measurement process versus the IPFIX metering process aspect.
There are many other aspects, as discussed in section 4 of [PSAMP-PROTO]
     4. Differences between PSAMP and IPFIX..........................4 
      4.1 Architecture Point of View.................................4 
      4.2 Protocol Point of View.....................................6 
      4.3 Information Model Point of View............................6
We have 2 solutions:
1. we cover all the differences also in this section
2. we refer to the [PSAMP-PROTO] in this draft
I guess that the solution 2 is better.

6. Section 5.2, under "Router State Filtering".
We know that the filtering definition says: 
        Filtering: a filter is a selection operation that selects a 
        packet deterministically based on the packet content, its 
        treatment, and functions of these occurring in the selection 
        state.
We must add a note that the "Router State Filtering" only deals with the packet treatment part of the definition.

7. The Trajectory Sampling definition in section 11.2 
      Trajectory sampling is the selection of a subset of packets at 
      either all of a set of observation points or none of them.
I think the "none of them" part of the definition is confusing.
I would write something like
      Trajectory sampling is the selection of a subset of packets at 
      either all of a specific Observation Points in the network (for
      example, all ingress interface).

Regards, Benoit.





--------------050207090903090605030906--

--------------020900030702040403060700
Content-Type: text/plain;
 name="draft-ietf-psamp-framework-08.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="draft-ietf-psamp-framework-08.txt"
Content-Transfer-Encoding: 8bit


    
                                                                         
   Internet Draft                               Nick Duffield (Editor) 
   Category: Informational                        AT&T Labs – Research 
   Document:              September 2004 
   Expires: March 2005                                                   
                                                                         
                                                                         
                                                                         
    
    
               A Framework for Packet Selection and Reporting 
    
    
   Status of this Memo 
    
      This document is an Internet-Draft and is in full conformance 
      with all provisions of Section 10 of RFC 2026.  
       
      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. 
       
   Abstract 
       
      This document specifies a framework for the PSAMP (Packet 
      SAMPling) protocol. The functions of this protocol are to select 
      packets from a stream according to a set of standardized 
      selectors, to form a stream of reports on the selected packets, 
      and to export the reports to a collector. This framework details 
      the components of this architecture, then describes some generic 
      requirements, motivated the dual aims of ubiquitous deployment 
      and utility of the reports for applications. Detailed 
      requirements for selection, reporting and exporting  processes 
      are described, along with configuration requirements of the PSAMP 
      functions. 
    
      Comments on this document should be addressed to the PSAMP 
      Working Group mailing list: psamp@ops.ietf.org 
       
      To subscribe: psamp-request@ops.ietf.org, in body: subscribe 
      Archive: https://ops.ietf.org/lists/psamp/ 
       
    
   Duffield (Ed.)            Expires March 2005                 [Page 1] 
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
   Table of Contents 
    
      1.   Introduction...............................................3 
      2.   PSAMP Documents Overview...................................4 
      3.   Elements, Terminology and High-level Architecture..........4 
      3.1  High-level description of the PSAMP Architecture ..........4 
      3.2  Observation Points, Packet Streams and Packet Content......5 
      3.3  Selection Process .........................................6 
      3.4  Reporting Process .........................................7 
      3.5  Measurement Process........................................8 
      3.6  Exporting Process .........................................8 
      3.7  PSAMP Device...............................................8 
      3.8  Collector..................................................8 
      3.9  Possible Configurations....................................9 
      3.10 PSAMP and IPFIX Interaction................................9 
      4.   Generic Requirements for PSAMP.............................9 
      4.1  Generic Selection Process Requirements....................10 
      4.2  Generic Reporting Process Requirements....................10 
      4.3  Generic Exporting process Requirements....................11 
      4.4  Generic Configuration Requirements........................11 
      5.   Packet Selection Operations...............................12 
      5.1  Two Types of Selection Operation..........................12 
      5.2  PSAMP Packet Selection Operations ........................12 
      5.3  Selection Rate Terminology................................14 
      5.4  Input Sequence Numbers for Primitive Selection Processes..15 
      5.5  Composite Selectors.......................................15 
      5.6  Constraints on the Sampling Frequency.....................16 
      6.   Reporting Process ........................................16 
      6.1  Mandatory Contents of Packet Reports......................16 
      6.2  Extended Packet Reports...................................17 
      6.3  Extended Packet Reports in the Presence of IPFIX .........17 
      6.4  Report Interpretation.....................................17 
      6.5  Export Packet Compression ................................18 
      7.   Parallel Measurement Processes............................18 
      8.   Exporting Process ........................................19 
      8.1  Use of IPFIX..............................................19 
      8.2  Congestion-aware Unreliable Transport.....................19 
      8.3  Limiting Delay for Export Packets ........................19 
      8.4  Configurable Export Rate Limit............................21 
      8.5  Collector Destination.....................................21 
      8.6  Local Export..............................................21 
      9.   Configuration and Management..............................21 
      10.  Feasibility and Complexity................................22 
      10.1 Feasibility...............................................22 
      10.1.1 Filtering...............................................22 
      10.1.2 Sampling ...............................................22 
      10.1.3 Hashing.................................................23 
      10.1.4 Reporting...............................................23 
      10.1.5 Export..................................................23 
      10.2 Potential Hardware Complexity.............................23 
      11.  Applications..............................................24 
      11.1 Baseline Measurement and Drill Down.......................25 
    
   Duffield (Ed.)            Expires March 2005                 [Page 2] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      11.2 Trajectory Sampling.......................................25 
      11.3 Passive Performance Measurement...........................25 
      11.4 Troubleshooting...........................................26 
      12.  Security Considerations...................................27 
      13.  Normative References......................................27 
      14.  Informative References....................................28 
      15.  Authors' Addresses........................................29 
      16.  Intellectual Property Statements..........................31 
      17.  Full Copyright Statement..................................31 
   
                                                               
      Copyright (C) The Internet Society (2004).  All Rights Reserved. 
      This document is an Internet-Draft and is in full conformance 
      with all provisions of Section 10 of RFC 2026. 
       
      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. 
          
      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. 
       
   1. Introduction 
       
      This document describes the PSAMP framework for network elements 
      to select subsets of packets by statistical and other methods, 
      and to export a stream of reports on the selected packets to a 
      collector.  
       
      The motivation for the PSAMP standard comes from the need for 
      measurement-based support for network management and control 
      across multivendor domains. This requires domain wide consistency 
      in the types of selection schemes available, the manner in which 
      the resulting measurements are presented, and consequently, 
      consistency of the interpretation that can be put on them. 
       

    
   Duffield (Ed.)            Expires March 2005                 [Page 3] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      The motivation for specific packet selection operations comes 
      from the applications that they enable. Development of the PSAMP 
      standard is open to influence by the requirements of standards in 
      related IETF Working Groups, for example, IP Performance Metrics 
      (IPPM) [RFC-2330] and Internet Traffic Engineering (TEWG).  
       
      The name PSAMP is a contraction of the phrase Packet Sampling. 
      The word “sampling” captures the idea that only a subset of all 
      packets passing a network element will be selected for reporting. 
      But PSAMP selection operations include random selection, 
      deterministic selection (filtering), and deterministic 
      approximations to random selection (hash-based selection). 
       
   2. PSAMP Documents Overview 
    
      PSAMP-FRAMEWORK: “A Framework for Packet Selection and 
      Reporting”: this document. This document describes the PSAMP 
      framework for network elements to select subsets of packets by 
      statistical and other methods, and to export a stream of reports 
      on the selected packets to a collector. Definitions of 
      terminology and the use of the terms “must”, “should” and “may” 
      in this document are informational only. 
       
      [PSAMP-TECH]: “Sampling and Filtering Techniques for IP Packet 
      Selection”, describes the set of packet selection techniques 
      supported by PSAMP. 
       
      [PSAMP-MIB]: “Definitions of Managed Objects for Packet Sampling” 
      describes the PSAMP Management Information Base  
       
      [PSAMP-PROTO]: “Packet Sampling (PSAMP) Protocol Specifications” 
      specifies the export of packet information from a PSAMP Exporting 
      Process to a PSAMP Colleting Process 
          
      [PSAMP-INFO]: “Information Model for Packet Sampling Exports” 
      defines an information and data model for PSAMP. 
       
   3. Elements, Terminology and High-level Architecture 
       
   3.1 High-level description of the PSAMP Architecture 
       
      Here is an informal high level description of the PSAMP protocol 
      operating in a PSAMP device (all terms will be defined 
      presently). A stream of packets is observed at an observation 
      point. A selection process inspects each packet to determine 
      whether it should be selected. A reporting process constructs a 
      report on each selected packet, using the packet content, and 
      possibly other information such as the packet treatment or the 
      arrival timestamp. An exporting process sends the reports to a 
      collector, together with any subsidiary information needed for 
      their interpretation.  
    
   Duffield (Ed.)            Expires March 2005                 [Page 4] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
    
      The following figure indicates the sequence of the three 
      processes (selection, reporting, and exporting) within the PSAMP 
      device. The composition of the selection process followed by the 
      reporting process is known as the measurement process. 
       
                 +---------+    +---------+    +---------+ 
       Observed  |Selection|    |Reporting|    |Exporting| 
       Packet--->|Process  |--->|Process  |--->|Process  |--->Collector   
       Stream    +---------+    +---------+    +---------+  
               \----Measurement Process-----/                         
    
      The following sections give the detailed definitions of each of 
      all the objects just named. 
    
   3.2 Observation Points, Packet Streams and Packet Content 
       
      This section contains the definition of terms relevant to 
      obtaining the packet input to the selection process.  
       
      * Observation Point  
       
        An observation point is a location in the network where packets 
        can be observed. Examples include: 
         
             (i) a line to which a probe is attached; 
             (ii) a shared medium, such as an Ethernet-based LAN; 
             (iii) a single port of a router, or set of interfaces 
             (physical or logical) of a router; 
             (iv) an embedded measurement subsystem within an 
        interface. 
              
        Note that one observation point may be a superset of several 
        other observation points.  For example one observation point 
        can be an entire line card.  This would be the superset of the 
        individual observation points at the line card's interfaces. 
       
      * Observed Packet Stream 
         
        The observed packet stream is the set of all packets observed 
        at the observation point. 
       
      * Packet Stream 
    
        A packet stream denotes a subset of the observed packet stream. 
         
      * Packet Content 
       
        The packet content denotes the union of the packet header 
        (which includes link layer, network layer and other 
        encapsulation headers) and the packet payload. 

    
   Duffield (Ed.)            Expires March 2005                 [Page 5] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
       
      Note that packets selected from a stream, e.g. by sampling, do 
      not necessarily possess a property by which they can be 
      distinguished from packets that have not been selected. For this 
      reason the term “stream” is favored over “flow”, which is defined 
      as set of packets with common properties [IPFIX-REQUIRE]. 
       
   3.3 Selection Process 
       
      This section defines the selection process and related objects. 
       
      * Selection Process 
         
        A selection process takes a packet stream as its input and 
        selects a subset of that stream as its output. 
         
      * Selection State:  
       
           A selection process may maintain state information for use 
           by the selection process and/or the reporting process. At a 
           given time, the selection state may depend on packets 
           observed at and before that time, and other variables. 
           Examples include: 
             
                  (i) sequence numbers of packets at the input of 
                  selectors; 
                   
                  (ii) a timestamp of observation of the packet at the 
                  observation point; 
                   
                  (iii) iterators for pseudorandom number generators; 
                
                  (iv) hash values calculated during selection; 
             
                  (v) indicators of whether the packet was selected by 
                  a given selector; 
                   
           Selection processes may change portions of the selection 
           state as a result of processing a packet. Selection state 
           for a packet is to reflect the state after processing the 
           packet. 
            
      * Selector:  
       
           A selector defines the action of a selection process on a 
           single packet of its input. A selected packet becomes an 
           element of the output packet stream of the selection 
           process. 
            
           The selector can make use of the following information in 
           determining whether a packet is selected: 
            
    
   Duffield (Ed.)            Expires March 2005                 [Page 6] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
           (i) the packet’s content; 
       
           (ii) information derived from the packet's treatment at the     
           observation point; 
       
           (iii) any selection state that may be maintained by the 
           selection process. 
            
      * Composite Selection Process:               
         
           A composite selection process is an ordered composition of 
           selection processes, in which the output stream issuing from 
           one component forms the input stream for the succeeding 
           component.  
            
      * Composite Selector:  
         
           A selector is composite if it defines a composite selection 
           process. 
    
      * Primitive Selection Process:  
       
           A selection process is primitive if it is not a composite a 
           selection process. 
            
      * Primitive Selector:  
       
           A selector is primitive if it defines a primitive selection 
           process. 
            
   3.4 Reporting Process 
       
      * Reporting Process:  
       
           A reporting process creates a report stream on packets 
           selected by a selection process, in preparation for export. 
           The input to the reporting process comprises that 
           information available to the selection process per selected 
           packet, specifically: 
            
             (i) the selected packet’s content; 
              
             (ii) information derived from the selected packet's 
             treatment at the observation point; 
              
             (iii) any selection state maintained by the inputting 
             selection process, reflecting any modifications to the 
             selection state made during selection of the packet. 
              
      * Packet Reports:  
            

    
   Duffield (Ed.)            Expires March 2005                 [Page 7] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
           Packet reports comprise a configurable subset of a packet’s 
           input to the reporting process, including the packet’s 
           content, information relating to its treatment  
           (for example, the output interface), and its associated 
           selection state (for example, a hash of the packet’s 
           content) 
    
      * Report Interpretation:  
            
           Report interpretation comprises subsidiary information, 
           relating to one or more packets, that is used for 
           interpretation of their packet reports. Examples include 
           configuration parameters of the selection process and of the 
           reporting process. 
    
      * Report Stream: 
            
           The report stream is the output of a reporting process, 
           comprising two distinguished types of information: packet 
           reports, and report interpretation. 
              
   3.5 Measurement Process 
    
      * A Measurement Process is the composition of a selection process 
        that takes the observed packet stream as its input, followed by 
        a reporting process. 
       
   3.6 Exporting Process 
       
      * Exporting Process:  
         
        An exporting process sends, in the form of export packet, the 
        output of one or more measurement processes to one or more 
        collectors.  
    
      * Export Packets:  
         
        a combination of report interpretation and/or one or more 
        packet reports are bundled by the exporting process into a 
        export packet for exporting to a collector. 
         
   3.7 PSAMP Device 
       
      A PSAMP Device is a device hosting at least an observation point, 
      a measurement process and an exporting process. Typically, 
      corresponding observation point(s), measurement process(es) and 
      exporting process(es) are co-located at this device, for example 
      at a router. 
       
   3.8 Collector 
       

    
   Duffield (Ed.)            Expires March 2005                 [Page 8] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      A collector receives a report stream exported by one or more 
      exporting processes. In some cases, the host of the measurement 
      and/or exporting processes may also serve as the collector. 
    
   3.9 Possible Configurations 
        
      Various possibilities for the high level architecture of these 
      elements are as follows. 
       
          MP = Measurement Process, EP = Exporting process 
       
          PSAMP Device 
         +---------------------+                 +------------------+ 
         |Observation Point(s) |                 | Collector(1)     | 
         |MP(s)--->EP----------+---------------->|                  |     
         |MP(s)--->EP----------+-------+-------->|                  | 
         +---------------------+       |         +------------------+ 
                                       | 
          PSAMP Device                 |     
         +---------------------+       |         +------------------+ 
         |Observation Point(s) |       +-------->| Collector(2)     | 
         |MP(s)--->EP----------+---------------->|                  | 
         +---------------------+                 +------------------+ 
             
          PSAMP Device                              
         +---------------------+          
         |Observation Point(s) |          
         |MP(s)--->EP---+      |          
         |              |      |          
         |Collector(3)<-+      | 
         +---------------------+   
       
   3.10    PSAMP and IPFIX Interaction 
       
      The PSAMP measurement process can be viewed as analogous to the 
      IPFIX metering process. The PSAMP measurement process takes an 
      observed packet stream as its input, and produces packet reports 
      as its output. The IPFIX metering process produces flow records 
      as its output. The distinct name “measurement process” has been 
      retained in order to avoid potential confusion in settings where 
      IPFIX and PSAMP coexist, and in order to avoid the implicit 
      requirement that the PSAMP version satisfy the requirements of an 
      IPFIX metering  process (at least while these are under 
      development). The relationship between PSAMP and IPFIX is 
      described more in [PSAMP-INFO].  
    
   4. Generic Requirements for PSAMP 
       
      This section describes the generic requirements for the PSAMP 
      protocol. A number of these are realized as specific requirements 
      in later sections. 
    
    
   Duffield (Ed.)            Expires March 2005                 [Page 9] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
   4.1 Generic Selection Process Requirements. 
       
      * Ubiquity: The selectors must be simple enough to be implemented 
        ubiquitously at maximal line rate. 
       
      * Applicability: the set of selectors must be rich enough to 
        support a range of existing and emerging measurement based 
        applications and protocols. This requires a workable trade-off 
        between the range of traffic engineering applications and 
        operational tasks it enables, and the complexity of the set of 
        capabilities. 
       
      * Extensibility: the protocol must be able to accommodate 
        additional packet selectors not currently defined. 
       
      * Flexibility: the protocol must support selection of packets 
        using various network protocols or encapsulation layers, 
        including Internet Protocol Version 4 (IPv4) [IPv4], Internet 
        Protocol Version 6 (IPv6) [RFC-2460], and Multiprotocol Label 
        Switching (MPLS) [RFC-3031].  
    
      * Robust Selection: packet selection must be robust against 
        attempts to craft an observed packet stream from which packets 
        are selected disproportionately (e.g. to evade selection, or 
        overload measurement systems). 
    
      * Parallel Measurement Processes: the protocol must support 
        simultaneous operation of multiple independent measurement 
        processes at the same host. 
       
      * Non-Contingency: the selection decision for each packet must 
        not depend on future packets.   
       
      * Encrypted Packets: selection operations based on interpretation 
        of packet fields must be configurable to ignore (i.e. not 
        select) encrypted packets, when they are detected.  
    
      Selectors are outlined in Section 5, and described in more detail 
      in the companion document [PSAMP-TECH].  
       
   4.2 Generic Reporting Process Requirements 
       
      * Self-defining: the report stream must be complete in the sense 
        that no additional information need be retrieved from the 
        observation point in order to interpret and analyze the 
        reports.   
       
      * Indication of Information Loss: the reports stream must include 
        sufficient information to indicate or allow the detection of 
        loss occurring within the selection, reporting or exporting 
        processes, or in transport. This may be achieved by the use of 
        sequence numbers. 
    
   Duffield (Ed.)            Expires March 2005                [Page 10] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
       
      * Accuracy: the report stream must include information that 
        enables the accuracy of measurements to be determined. 
       
      * Faithfulness: all reported quantities that relate to the packet 
        treatment must reflect the router state and configuration 
        encountered by the packet at the time it is received by the 
        measurement process. 
       
      * Privacy: selection of the content of packet reports will be 
        cognizant of privacy and anonymity issues while being 
        responsive to the needs of measurement applications, and in 
        accordance with [RFC-2804].  Full packet capture of arbitrary 
        packet streams is explicitly out of scope. 
    
      A specific reporting process meeting these requirements, and the 
      requirement for ubiquity, is described in Section 6. 
       
   4.3 Generic Exporting process Requirements 
       
      * Timeliness: configuration must allow for limiting of buffering 
        delays for the formation and transmission for export reports. 
        See Section Error! Reference source not found. for further 
        details. 
       
      * Congestion Avoidance: export of a report stream across a 
        network must be congestion avoiding in compliance with [RFC-
        2914]. 
       
      * Secure Export: 
              
        (i) confidentiality: the option to encrypt exported data must 
        be provided. 
     
        (ii) integrity: alterations in transit to exported data must be 
        detectable at the collector 
              
        (iii) authenticity: authenticity of exported data must be 
        verifiable by the collector in order to detect forged data. 
       
      The motivation here is the same as for security in IPFIX export; 
      see Sections 6.3 and 10 of [IPFIX-REQUIRE].   
       
   4.4 Generic Configuration Requirements 
       
      * Ease of Configuration: of sampling and export parameters, e.g. 
        for automated remote reconfiguration in response to collected 
        reports. 
       
      * Secure Configuration: the option to configure via protocols 
        that prevent unauthorized reconfiguration or eavesdropping on 
        configuration communications must be available.  Eavesdropping 
    
   Duffield (Ed.)            Expires March 2005                [Page 11] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
        on configuration might allow an attacker to gain knowledge that 
        would be helpful in crafting a packet stream to evade 
        subversion, or overload the measurement infrastructure. 
    
      Configuration is discussed in Section 9. Feasibility and 
      complexity of PSAMP operations is discussed in Section 10. 
    
   5. Packet Selection Operations 
       
   5.1 Two Types of Selection Operation 
    
      PSAMP categorizes selection operations into two types: 
       
      * Filtering: a filter is a selection operation that selects a 
        packet deterministically based on the packet content, its 
        treatment, and functions of these occurring in the selection 
        state. Two examples are: 
       
           (i) Mask/match filtering.  
              
           (ii) Hash-based selection: a hash function is applied to the 
             packet content, and the packet is selected if the result 
             falls in a specified range. 
       
      * Sampling: a selection operation that is not a filter is called 
        a sampling operation. This reflects the intuitive notion that 
        if the selection of a packet cannot be determined from its 
        content alone, there must be some type of sampling taking 
        place.  
         
        Sampling operations can be divided into two subtypes: 
    
           (i) Content-independent Sampling, which does not use packet 
             content in reaching sampling decisions. Examples include 
             periodic sampling, and uniform pseudorandom sampling 
             driven by a pseudorandom number whose generation is 
             independent of packet content. Note that in content-
             independent sampling it is not necessary to access the 
             packet content in order to make the selection decision. 
       
           (ii) Content-dependent Sampling, in which the packet content is 
             used in reaching selection decisions. Examples include 
             pseudorandom selection according to a probability that 
             depends on the contents of a packet field; note that this 
             is not a filter. 
       
   5.2 PSAMP Packet Selection Operations 
       
      A spectrum of packet selection operations is described in detail 
      in [PSAMP-TECH]. Here we only briefly summarize the meanings for 
      completeness. 
    
    
   Duffield (Ed.)            Expires March 2005                [Page 12] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      A PSAMP selection process must support at least one of the 
      following selectors. 
          
      * Systematic Time Based Sampling: packet selection is triggered 
        at periodic instants separated by a time called the spacing. 
        All packets that arrive within a certain time of the trigger 
        (called the interval length) are selected. 
       
      * Systematic Count Based Sampling: similar to systematic time 
        based expect that selection is reckoned with respect to packet 
        count rather than time. Packet selection is triggered 
        periodically by packet count, a number of successive packets 
        being selected subsequent to each trigger. 
       
      * Uniform Probabilistic Sampling: packets are selected 
        independently with fixed sampling probability p. 
       
      * Non-uniform Probabilistic Sampling: packets are selected 
        independently with probability p that depends on packet 
        content. 
       
      * Probabilistic n-out-of-N Sampling: form each count-based 
        successive block of N packets, n are selected at random.  
       
      * Mask/match Filtering: this entails taking the masking portions 
        of the packet (i.e. taking the logical “and” with a binary 
        mask) and selecting the packet if the result falls in a range 
        specified in the selection parameters of the filter.  This 
        specification does not preclude the future definition of a high 
        level syntax for defining filtering in a concise way (e.g. TCP 
        port taking a particular value) providing that syntax can be 
        compiled into the bitwise expression. 
         
        Mask/match operations should be available for different 
        protocol portions of the packet header: 
    
           (i) the IP header (excluding options in IPv4, stacked 
           headers in IPv6) 
            
           (ii) transport header 
            
           (iii) encapsulation headers (e.g. the MPLS label stack) if 
           present) 
         
        When the PSAMP device offers mask/match filtering, and, in its 
        usual capacity other than in performing PSAMP functions, 
        identifies or processes information from one or more of the 
        above protocols, then the information should be made available 
        for filtering. For example, when a PSAMP device routes based on 
        destination IP address, that field should be made available for 
        filtering. Conversely, a PSAMP device that does not route is 
        not expected to be able to locate an IP address within a 
    
   Duffield (Ed.)            Expires March 2005                [Page 13] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
        packet, or make it available for filtering, although it may do 
        so. 
         
        Since packet encryption alters the meaning of encrypted fields, 
        Mask/Match filtering must be configurable to ignore encrypted 
        packets, when detected. 
       
        Hash-based Selection: Hash-based selection will employ one or 
        more hash functions to be standardized.  A hash function is 
        applied to a subset of packet content, and the packet is 
        selected of the resulting hash falls in a specified range. With 
        a suitable hash function, hash based selection approximates 
        uniform random sampling. Applications of hash-based sampling 
        are described in Section 11.  
         
      * Router State Filtering: the selection process may support 
        filtering based on the following conditions, which may be 
        combined with the logical "and", "or" or "not" operators:  
    
           (i) Ingress interface at which packet arrives equals a 
           specified value 
           (ii) Egress interface to which packet is routed to equals a 
           specified value 
           (iii) Packet violated Access Control List (ACL) on the 
           router 
           (iv) Failed Reverse Path Forwarding (RPF) 
           (v) Failed Resource Reservation (RSVP) 
           (vi) No route found for the packet 
           (vii) Origin Border Gateway Protocol (BGP) Autonomous System 
           (AS) equals a specified value or lies within a given range 
           (viii) Destination BGP AS equals a specified value or lies 
           within a given range 
    
       Router architectural considerations may preclude some 
       information concerning the packet treatment, e.g. routing state, 
       being available at line rate for selection of packets. However, 
       if selection not based on routing state has reduced down from 
       line rate, subselection based on routing state may be feasible. 
       
       This section detailed specific requirements for the selection 
       process, motivated by the generic requirement of Section 3.3. 
    
   5.3 Selection Rate Terminology 
       
      The proportion of packets that are selected by a selection 
      operation is figured in two ways: 
       
      * Attained Selection Frequency: the actual frequency with which 
        packets are selected by a selection process. When packets are 
        selected from a set of packets in a stream, the attained 
        sampling frequency is calculated as ratio of the number of 
        packets selected to the number of packets in the set.  
    
   Duffield (Ed.)            Expires March 2005                [Page 14] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
       
      * Target Selection Frequency: the average frequency with which 
        packets are expected to be selected, based on selector 
        parameter settings.  
         
        For sampling operations, due to the inherent statistical 
        variability of sampling decisions, the target and attained 
        selection frequencies will not in general be equal, although 
        they may be close in some circumstances, e.g., when the 
        population size is large.  
    
   5.4 Input Sequence Numbers for Primitive Selection Processes 
         
      Each instance of a primitive selection process must maintain a 
      count of packets presented at its input. The counter value is to 
      be included as a sequence number for selected packets. The 
      sequence numbers are considered as part of the packet's selection 
      state. 
       
      Use of input sequence numbers enables applications to determine 
      the attained selection frequency, and hence correctly normalize 
      network usage estimates regardless of loss of information, 
      regardless of whether this loss occurs because of discard of 
      packet reports in the measurement or reporting process (e.g. due 
      to resource contention in the host of these processes), or loss 
      of export packets in transmission or collection. See [RFC-3176] 
      for further details. 
       
      As an example, consider a set of n consecutive packet reports r1, 
      r2,... , rn, selected by a sampling operation and received at a 
      collector. Let s1, s2,..., sn be the input sequence numbers 
      reported by the packets. The attained selection frequency, taking 
      into account both packet sampling at the observation point and 
      selection arising from loss in transmission, is R = (n-1)/(sn-
      s1). (Note R would be 1 if all packets were selected and there 
      were no transmission loss). 
       
      The attained selection frequency can be used to estimate the 
      number bytes present in a portion of the observed packet stream. 
      Let b1, b2,..., bn be the bytes reported in each of the packets 
      that reached the collector, and set B = b1+b2+...+bn. Then the 
      total bytes present in packets in the observed packet stream 
      whose input sequence numbers lie between s1 and sn is estimated 
      by B/R, i.e, scaling up the measured bytes through division by 
      the attained selection frequency. 
       
      With composite selectors, and input sequence number must be 
      reported for each selector in the composition. 
    
   5.5 Composite Selectors 
       

    
   Duffield (Ed.)            Expires March 2005                [Page 15] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      The ability to compose selectors in a selection process should be 
      provided. The following combinations appear to be most useful for 
      applications: 
             
      * filtering followed by sampling 
         
      * sampling followed by filtering 
       
      Composite selectors are useful for drill down applications. The 
      first component of a composite selector can be used to reduce the 
      load on the second component. In this setting, the advantage to 
      be gained from a given ordering can depend on the composition of 
      the packet stream. 
       
   5.6 Constraints on the Sampling Frequency 
    
      Sampling at full line rate, i.e. with probability 1, is not 
      excluded in principle, although resource constraints may not 
      support it in practice. 
       
   6. Reporting Process 
       
      This section detailed specific requirements for the reporting 
      process, motivated by the generic requirement of Section 3.4 
       
   6.1 Mandatory Contents of Packet Reports 
       
      The reporting process must include the following in each packet 
      report: 
       
           (i) the input sequence number(s) of any sampling operation 
             that acted on the packet in the instance of a measurement 
             process of which the reporting process is a component. 
       
      The reporting process must support inclusion of the following in 
      each packet report, as a configurable option: 
       
           (ii) a basic report on the packet, i.e., some number of 
           contiguous bytes from the start of the packet, including the 
           packet header (which includes link layer, network layer and 
           other encapsulation headers) and some subsequent bytes of 
           the packet payload. 
            
      Some devices hosting reporting processes may not have the 
      resource capacity or functionality to provide more detailed 
      packet reports that those in (i) and (ii) above. Using this 
      minimum required reporting functionality, the reporting process 
      places the burden of interpretation on the collector, or on 
      applications that it supplies. Some devices may have the 
      capability to provide extended packet reports, described in the 
      next section.  
    
    
   Duffield (Ed.)            Expires March 2005                [Page 16] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
   6.2 Extended Packet Reports 
    
      The reporting process may support inclusion in packet reports of 
      the following information, inclusion any or all being 
      configurable as an option. 
       
           (iii) fields relating to the following protocols used in the 
           packet: IPv4, IPV6, transport protocols, MPLS. 
             
           (iv) packet treatment, including: 
       
            - identifiers for any input and output interfaces of the 
           observation point that were traversed by the packet 
             
            - source and destination BGP AS 
       
           (v) selection state associated with the packet, including: 
       
           - the timestamp of observation of the packet at the 
           observation point. The timestamp should be reported to 
           microsecond resolution.  
       
           - hashes, where calculated. 
       
       It is envisaged that selection of fields for extended packet 
       reporting may be used to reduce reporting bandwidth, in which 
       case the option to report information in (ii) may not be 
       exercised. 
    
   6.3 Extended Packet Reports in the Presence of IPFIX 
       
      If an IPFIX metering process is supported at the observation 
      point, then in order to be PSAMP compliant, extended packet 
      reports must be able to include all fields required in the IPFIX 
      information model [IPFIX-INFO], with modifications appropriate to 
      reporting on single packets rather than flows. 
    
   6.4  Report Interpretation 
    
      Information for use in report interpretation must include  
       
           (i) configuration parameters of the selectors of the packets 
           reported on.  
            
           (ii) format of the packet report; 
            
           (iii) indication of the inherent accuracy of the reported 
           quantities, e.g., of the packet timestamp.  
            
           (iv) identifiers for observation point, measurement process, 
           and exporting process.  
    
    
   Duffield (Ed.)            Expires March 2005                [Page 17] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      The accuracy measure in (iii) is of fundamental importance for 
      estimating the likely error attached to estimates formed from the 
      packet reports by applications. 
       
      Identifiers in (iv) are necessary, e.g., in order to match packet 
      reports to the selection process that selected them. For example, 
      when packet reports due to a sampling operation suffer loss 
      (either during export, or in transit) it may be desirable to 
      reconfigure downwards the sampling rate on the selection process 
      that selected them.  
       
      The requirements for robustness and transparency are motivations 
      for including report interpretation in the report stream. 
      Inclusion makes the report stream self-defining.  The PSAMP 
      framework excludes reliance on an alternative model in which 
      interpretation is recovered out of band. This latter approach is 
      not robust with respect to undocumented changes in selector 
      configuration, and may give rise to future architectural problems 
      for network management systems to coherently manage both 
      configuration and data collection. 
       
      It is not envisaged that all report interpretation be included in 
      every packet report. Many of the quantities listed above are 
      expected to be relatively static; they could be communicated 
      periodically, and upon change. 
    
   6.5 Export Packet Compression 
       
      To conserve network bandwidth and resources at the collector, the 
      export packets may be compressed before export.  Compression is 
      expected to be quite effective since the sampled packets may 
      share many fields in common, e.g. if a filter focuses on packets 
      with certain values in particular header fields. Using 
      compression, however, could impact the timeliness of packet 
      reports. Any consequent delay must not violate the timeliness 
      requirement for availability of packet reports at the collector. 
    
   7. Parallel Measurement Processes 
       
      Because of the increasing number of distinct measurement 
      applications, with varying requirements, it is desirable to set 
      up parallel measurement processes on given observed packet 
      stream. A device capable of hosting a measurement process should 
      be able to support more than one independently configurable 
      measurement process simultaneously. Each such measurement process 
      should have the option of being equipped with its own exporting 
      process; otherwise the parallel measurement processes may share 
      the same exporting process.  
       
      Each of the parallel measurement processes should be independent. 
      However, resource constraints may prevent complete reporting on a 
      packet selected by multiple selection processes. In this case, 
    
   Duffield (Ed.)            Expires March 2005                [Page 18] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      reporting for the packet must be complete for at least one 
      measurement process; other measurement processes need only record 
      that they selected the packet, e.g., by incrementing a counter. 
      The priority amongst measurement processes under resource 
      contention should be configurable. 
       
      It is not proposed to standardize the number of parallel 
      measurement processes. 
       
   8. Exporting Process 
       
      This section detailed specific requirements for the exporting 
      process, motivated by the generic requirements of Section 3.6 
       
   8.1 Use of IPFIX 
       
      PSAMP will use the IP Flow Information eXport (IPFIX) protocol 
      for export of the report stream. The IPFIX protocol is well 
      suited for this purpose, because the IPFIX architecture matches 
      the PSAMP architecture very well and the means provided by the 
      IPFIX protocol are sufficient.  
       
   8.2 Congestion-aware Unreliable Transport 
    
      The export of the report stream does not require reliable export.  
      Section 5.4 shows that the use of input sequence number in packet 
      selectors means that the ability to estimate traffic rates is not 
      impaired by export loss. Export packet loss becomes another form 
      of sampling, albeit a less desirable, and less controlled, form 
      of sampling. 
       
      On the contrary, retransmission of lost export packets consumes 
      additional network resources. The requirement to store 
      unacknowledged data is an impediment to having ubiquitous support 
      for PSAMP. 
       
      In order to jointly satisfy the timeliness and congestion 
      avoidance requirements of Section 4.3, a congestion aware 
      unreliable transport protocol must be used. IPFIX is compatible 
      with this requirement, since it mandates support of the Stream 
      Control Transmission Protocol (SCTP) [SCTP] and the SCTP Partial 
      Reliability Extension [RFC-3758]. IPFIX also allows the use of 
      User Datagram Protocol (UDP) [UDP] although it is not a 
      congestion aware protocol. However, in this case, the Export 
      Packets must remain wholly within the administrative domains of 
      the operators [IPFIX-PROTO]. 
       
   8.3 Limiting Delay for Export Packets 
          
      Low measurement latency allows the traffic monitoring system to 
      be more responsive to real-time network events, for example, in 
      quickly identifying sources of congestion. Timeliness is 
    
   Duffield (Ed.)            Expires March 2005                [Page 19] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      generally a good thing for devices performing the sampling since 
      it minimizes the amount of memory needed to buffer samples. 
       
      Keeping the packet dispatching delay small has other benefits 
      besides limiting buffer requirements. For many applications a 
      resolution of 1 second is sufficient. Applications in this 
      category would include: identifying sources associated with 
      congestion; tracing denial of service attacks through the network 
      and constructing traffic matrices. Furthermore, keeping dispatch 
      delay within the resolution required by applications eliminates 
      the need for timestamping by synchronized clocks at observation 
      points, or for the observation points and collector to maintain 
      bi-directional communication in order to track clock offsets. The 
      collector can simply process packet reports in the order that 
      they are received, using its own clock as a "global" time base. 
      This avoids the complexity of buffering and reordering samples. 
      See [DuGeGr02] for an example. 
       
      The delay between observation of a packet and transmission of a 
      export packet containing a report on that packet has several 
      components. It is difficult to standardize a given numerical 
      delay requirement, since in practice the delay may be sensitive 
      to processor load at the observation point. Therefore, PSAMP aims 
      to control that portion of the delay within the observation point 
      that is due to buffering in the formation and transmission of 
      export packets.  
    
      In order to limit delay in the formation of export packets, the 
      exporting process must provide the ability to close out and 
      enqueue for transmission any export packet in formation as soon 
      as it includes one packet report. This could be achieved, for 
      example, by the following means: 
       
          -      the number of packet reports per export packet is not 
                  to exceed a maximum value, which can be configured to 
                  take the value 1. 
                   
          -      the ability to exclude report interpretation from any 
                  export packet that contains a packet report; 
       
      In order to limit the delay in the transmission of export 
      packets, a configurable upper bound to the delay of an export 
      packet prior to transmission must be provided. If the bound is 
      exceeded the export packet is dropped. This functionality can be 
      provided by the timed reliability service of the SCTP Partial 
      Reliability Extension [RFC-3758]. 
       
      The exporting process may queue the report stream in order to 
      export multiple packet reports in a single export packet. Any 
      consequent delay must still allow for timely availability of 
      packet reports as just described. The timed reliability service 
      of the SCTP Partial Reliability Extension [RFC-3758] allows from 
    
   Duffield (Ed.)            Expires March 2005                [Page 20] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      the dropping of packets from the export buffer once their age in 
      the buffer exceeds a configurable bound. 
       
   8.4 Configurable Export Rate Limit 
       
      The exporting process must have an export rate limit, 
      configurable per exporting process. This is useful for two 
      reasons: 
       
           (i) Even without network congestion, the rate of packet 
           selection may exceed the capacity of the collector to 
           process reports, particularly when many exporting processes 
           feed a common collector. Use of an export rate limit allows 
           control of the global input rate to the collector. 
       
           (ii) IPFIX provides export using UDP as the transport 
           protocol in some circumstances. An export rate limit allows 
           the capping of the export rate to match both path link 
           speeds and the capacity of the collector.  
    
   8.5 Collector Destination 
    
      When exporting to a remote collector, the collector is identified 
      by IP address, transport protocol, and transport port number. 
       
   8.6 Local Export 
       
      The report stream may be directly exported to on-board 
      measurement based applications, for example those that form 
      composite statistics from more than one packet. Local export may 
      be presented through an interface direct to the higher level 
      applications, i.e., through an API, rather than employing the 
      transport used for off-board export. Specification of such an API 
      is outside the scope of the PSAMP framework. 
       
      A possible example of local export could be that packets selected 
      by the PSAMP measurement process serve as the input for the IPFIX 
      protocol, which then forms flow records out of the stream of 
      selected packets.  
    
   9. Configuration and Management 
       
      A key requirement for PSAMP is the easy reconfiguration of the 
      parameters of the measurement process: those for selection, 
      packet reports and export. Examples are  
       
           (i) support of measurement-based applications that want to 
           drill-down on traffic detail in real-time;  
            
           (ii) collector-based rate reconfiguration. 
       

    
   Duffield (Ed.)            Expires March 2005                [Page 21] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      To facilitate reconfiguration and retrieval of parameters, they 
      are to reside in a Management Information Base (MIB). Mandatory 
      configuration, capabilities and monitoring objects will cover all 
      mandatory PSAMP functionality. 
       
      Secondary objects will cover the recommended and optional PSAMP 
      functionality, and must be provided when such functionality is 
      offered by a PSAMP device. Such PSAMP functionality includes 
      configuration of offered selectors, composite selectors, multiple 
      measurement processes, and report format including the choice of 
      fields to be reported. For further details concerning the PSAMP 
      MIB, see [PSAMP-MIB]. 
       
      PSAMP requires a uniform mechanism with which to access and 
      configure the MIB. SNMP access must be provided by the host of 
      the MIB. 
    
   10.       Feasibility and Complexity 
       
      In order for PSAMP to be supported across the entire spectrum of 
      networking equipment, it must be simple and inexpensive to 
      implement.  One can envision easy-to-implement instances of the 
      mechanisms described within this draft. Thus, for that subset of 
      instances, it should be straightforward for virtually all system 
      vendors to include them within their products. Indeed, sampling 
      and filtering operations are already realized in available 
      equipment. 
       
      Here we give some specific arguments to demonstrate feasibility 
      and comment on the complexity of hardware implementations. We 
      stress here that the point of these arguments is not to favor or 
      recommend any particular implementation, or to suggest a path for 
      standardization, but rather to demonstrate that the set of 
      possible implementations is not empty. 
       
   10.1     Feasibility 
          
   10.1.1  Filtering 
       
      Filtering consists of a small number of mask (bit-wise logical), 
      comparison and range (greater than) operations.  Implementation 
      of at least a small number of such operations is straightforward. 
      For example, filters for security access control lists (ACLs) are 
      widely implemented. This could be as simple as an exact match on 
      certain fields, or involve more complex comparisons and ranges. 
       
   10.1.2  Sampling 
       
      Sampling based on either counters (counter set, decrement, test 
      for equal to zero) or range matching on the hash of a packet 
      (greater than) is possible given a small number of selectors, 

    
   Duffield (Ed.)            Expires March 2005                [Page 22] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      although there may be some differences in ease of implementation 
      for hardware vs. software platforms. 
       
   10.1.3  Hashing  
          
      Hashing functions vary greatly in complexity.  Execution of a 
      small number of sufficient simple hash functions is implementable 
      at line rate. Concerning the input to the hash function, hop-
      invariant IP header fields (IP address, IP identification) and 
      TCP/UDP header fields (port numbers, TCP sequence number) drawn 
      from the first 40 bytes of the packet have been found to possess 
      a considerable variability; see [DuGr01]. 
       
   10.1.4  Reporting 
       
      The simplest packet report would duplicate the first n bytes of 
      the packet. However, such an uncompressed format may tax the 
      bandwidth available to the reporting process for high sampling 
      rates; reporting selected fields would save on this bandwidth. 
      Thus there is a trade-off between simplicity and bandwidth 
      limitations. 
       
   10.1.5  Export 
       
      Ease of exporting export packets depends on the system 
      architecture. Most systems should be able to support export by 
      insertion of export packets, even through the software path. 
        
   10.2    Potential Hardware Complexity 
       
      We now comment on the complexity of possible hardware 
      implementations. Achieving low constants for performance while 
      minimizing hardware resources is, of course, a challenge, 
      especially at very high clock frequencies. Most of these 
      operations, however, are very basic and their implementations 
      very well understood; in fact, the average ASIC designer simply 
      uses canned library instances of these operations rather than 
      design them from scratch. In addition, networking equipment 
      generally does not need to run at the fastest clock rates, 
      further reducing the effort required to get reasonably efficient 
      implementations. 
       
      Simple bit-wise logical operations are easy to implement in 
      hardware.  Such operations (NAND/NOR/XNOR/NOT) directly translate 
      to four-transistor gates.  Each bit of a multiple-bit logical 
      operation is completely independent and thus can be performed in 
      parallel incurring no additional performance cost above a single 
      bit operation. 
       
      Comparisons (EQ/NEQ) take O(lg(M)) stages of logic, where M is 
      the number of bits involved in the comparison.  The lg(M) is 
      required to accumulate the result into a single bit. 
    
   Duffield (Ed.)            Expires March 2005                [Page 23] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
       
      Greater than operations, as used to determine whether a hash 
      falls in a selection range, are a determination of the most 
      significant not-equivalent bit in the two operands.  The operand 
      with that most-significant-not-equal bit set to be one is greater 
      than the other.  Thus, a greater than operation is also an 
      O(lg(M)) stages of logic operation. Optimized implementations of 
      arithmetic operations are also O(lg(M)) due to propagation of the 
      carry bit. 
       
      Setting a counter is simply loading a register with a state. Such 
      an operation is simple and fast O(1).  Incrementing or 
      decrementing a counter is a read, followed by an arithmetic 
      operation followed by a store.  Making the register dual-ported 
      does take additional space, but it is a well-understood 
      technique.  Thus, the increment/decrement is also an O(lg(M)) 
      operation. 
       
      Hashing functions come in a variety of forms.  The computation 
      involved in a standard Cyclic Redundancy Code (CRC) for example 
      are essentially a set of XOR operations, where the intermediate 
      result is stored and XORed with the next chunk of data.  There 
      are only O(1) operations and no log complexity operations.  Thus, 
      a simple hash function, such as CRC or generalizations thereof, 
      can be implemented in hardware very efficiently. 
       
      At the other end of the range of complexity, the MD5 function 
      uses a large number of bit-wise conditional operations and 
      arithmetic operations.  The former are O(1) operations and the 
      latter are O(lg(M)). MD5 specifies 256 32b ADD operations per 16B 
      of input processed.  Consider processing 10Gb/sec at 100MHz (this 
      processing rate appears to be currently available). This requires 
      processing 12.5B/cycle, and hence at least 200 adders, a sizeable 
      number. Because of data dependencies within the MD5 algorithm, 
      the adders cannot be simply run in parallel, thus requiring 
      either faster clock rates and/or more advanced architectures. 
      Thus, selection hashing functions as complex as MD5 may be 
      precluded for ubiquitous use at full line rate. This motivates 
      exploring the use of selection hash functions with complexity 
      somewhere between that of MD5 and CRC. However, identification 
      hashing with MD5 on only selected packets is feasible at a 
      sufficiently low sampling frequency. 
          
   11.       Applications  
          
      We first describe several representative operational applications 
      that require traffic measurements at various levels of temporal 
      and spatial granularity. Some of the goals here appear similar to 
      those of IPFIX, at least in the broad classes of applications 
      supported. The major benefit of PSAMP is the support of new 
      network management applications, specifically, those enabled by 
      the packet selectors that it supports.  
    
   Duffield (Ed.)            Expires March 2005                [Page 24] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
       
   11.1    Baseline Measurement and Drill Down 
       
      Packet sampling is ideally suited to determine the composition of 
      the traffic across a network. The approach is to enable 
      measurement on a cut-set of the network links such that each 
      packet entering the network is seen at least once, for example, 
      on all ingress links. Unfiltered sampling with a relatively low 
      frequency establishes baseline measurements of the network 
      traffic. Packet reports include packet attributes of common 
      interest: source and destination address and port numbers, 
      prefix, protocol number, type of service, etc. Traffic matrices 
      are indicated by reporting source and destination AS matrices. 
      Absolute traffic volumes are estimated by renormalizing the 
      sampled traffic volumes through division by either the target 
      sampling frequency, or by the attained sampling frequency (as 
      derived by interface packet counters included in the report 
      stream) 
       
      Suppose an operator or a measurement-based application detects an 
      interesting subset of a packet stream, as identified by a 
      particular packet attribute. Real-time drill-down to that subset 
      is achieved by instantiating a new measurement process on the 
      same packet stream from which the subset was reported. The 
      selection process of the new measurement process filters 
      according to the attribute of interest, and composes with 
      sampling if necessary to manage the frequency of packet 
      selection. 
       
   11.2    Trajectory Sampling 
       
      Trajectory sampling is the selection of a subset of packets at 
      either all of a set of observation points or none of them. 
      Trajectory sampling is realized by hash-based sampling if all 
      observation points in the set apply a common hash function to a 
      portion of the packet content that is invariant along the packet 
      path. (Thus, fields such at TTL and CRC are excluded).  
       
      The trajectory followed by a packet is reconstructed from PSAMP 
      reports on it that reach the collector. Reports on a given packet 
      are associated either by matching a label comprising the 
      invariant reported packet content, or possibly some digest of it. 
      The reconstruction of trajectories, and methods for dealing with 
      possible ambiguities due to label collisions (identical labels 
      reported by different packets) and potential loss of reports in 
      transmission are dealt with in [DuGr01], [DuGeGr02] and [DuGr04]. 
       
   11.3    Passive Performance Measurement 
         
      Trajectory sampling enables the tracking of the performance 
      experience by customer traffic, customers identified by a list of 
      source or destination prefixes, or by ingress or egress 
    
   Duffield (Ed.)            Expires March 2005                [Page 25] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      interfaces. Operational uses include the verification of Service 
      Level Agreements (SLAs), and troubleshooting following a customer 
      complaint. 
       
      In this application, trajectory sampling is enabled at all 
      network ingress and egress interfaces. Rates of loss in transit 
      between ingress and egress are estimated from the proportion of 
      trajectories for which no egress report is received. Note that 
      loss of customer packets is distinguishable from loss of packet 
      reports through use of report sequence numbers. Assuming 
      synchronization of clocks between different entities, delay of 
      customer traffic across the network may also be measured; see 
      [Zs02]. 
       
      Extending hash-selection to all interfaces in the network would 
      enable attribution of poor performance to individual network 
      links. 
       
   11.4    Troubleshooting 
       
      PSAMP reports can also be used to diagnose problems whose 
      occurrence is evident from aggregate statistics, per interface 
      utilization and packet loss statistics.  These statistics are 
      typically moving averages over relatively long time windows, 
      e.g., 5 minutes, and serve as a coarse-grain indication of 
      operational health of the network. The most common method of 
      obtaining such measurements are through the appropriate SNMP MIBs 
      (MIB-II [RFC-1213] and vendor-specific MIBs.) 
       
      Suppose an operator detects a link that is persistently 
      overloaded and experiences significant packet drop rates. There 
      is a wide range of potential causes: routing parameters (e.g., 
      OSPF link weights) that are poorly adapted to the traffic matrix, 
      e.g., because of a shift in that matrix; a denial of service 
      attack or a flash crowd; a routing problem (link flapping). In 
      most cases, aggregate link statistics are not sufficient to 
      distinguish between such causes, and to decide on an appropriate 
      corrective action. For example, if routing over two links is 
      unstable, and the links flap between being overloaded and 
      inactive, this might be averaged out in a 5 minute window, 
      indicating moderate loads on both links. 
       
      Baseline PSAMP measurement of the congested link, as described in 
      Section 11.1, enables measurements that are fine grained in both 
      space and time. The operator has to be able to determine how many 
      bytes/packets are generated for each source/destination address, 
      port number, and prefix, or other attributes, such as protocol 
      number, MPLS forwarding equivalence class (FEC), type of service, 
      etc. This allows the precise determination of the nature of the 
      offending traffic. For example, in the case of a Distributed 
      Denial of Service(DDoS) attack, the operator would see a 

    
   Duffield (Ed.)            Expires March 2005                [Page 26] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      significant fraction of traffic with an identical destination 
      address. 
       
      In certain circumstances, precise information about the spatial 
      flow of traffic through the network domain is required to detect 
      and diagnose problems and verify correct network behavior. In the 
      case of the overloaded link, it would be very helpful to know the 
      precise set of paths that packets traversing this link follow. 
      This would readily reveal a routing problem such as a loop, or a 
      link with a misconfigured weight. More generally, complex 
      diagnosis scenarios can benefit from measurement of traffic 
      intensities (and other attributes) over a set of paths that is 
      constrained in some way. For example, if a multihomed customer 
      complains about performance problems on one of the access links 
      from a particular source address prefix, the operator should be 
      able to examine in detail the traffic from that source prefix 
      which also traverses the specified access link towards the 
      customer. 
       
      While it is in principle possible to obtain the spatial flow of 
      traffic through auxiliary network state information, e.g., by 
      downloading routing and forwarding tables from routers, this 
      information is often unreliable, outdated, voluminous, and 
      contingent on a network model. For operational purposes, a direct 
      observation of traffic flow provided by trajectory sampling is 
      more reliable, as it does not depend on any such auxiliary 
      information. For example, if there was a bug in a router's 
      software, direct observation would allow the diagnosis the effect 
      of this bug, while an indirect method would not.  
       
   12.       Security Considerations 
       
         Security considerations are addressed in: 
        
         - Section 4.1: item Robust Selection 
         - Section 4.3: item Secure Export   
         - Section 4.4: item Secure Configuration 
         
   13.       Normative References 
       
           [PSAMP-TECH] T. Zseby, M. Molina, F. Raspall, N. G. Duffield, 
              Sampling and Filtering Techniques for IP Packet 
              Selection, RFC XXXX. [Currently Internet Draft, draft-
              ietf-psamp-sample-tech-04.txt, work in progress, February 
              2004. 
       
           [PSAMP-MIB] T. Dietz, B. Claise, Definitions of Managed 
              Objects for Packet Sampling, RFC XXXX. [Currently 
              Internet Draft, draft-ietf-psamp-mib-03.txt, work in 
              progress, July 2004.] 
            

    
   Duffield (Ed.)            Expires March 2005                [Page 27] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
           [PSAMP-PROTO] B. Claise (Ed.) Packet Sampling (PSAMP) 
              Protocol Specifications, RFC XXXX. [Currently Internet 
              Draft draft-ietf-psamp-protocol-01.txt, work in progress, 
              February 2004.] 
            
           [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, 
              Information Model for Packet Sampling Exports, RFC XXXX.  
              [Currently Internet Draft, draft-ietf-psamp-info-02, July  
              2004 
       
       
   14.       Informative References 
       
           [B88] R.T. Braden, A pseudo-machine for packet monitoring 
              and statistics, in Proc ACM SIGCOMM 1988 
       
           [IPFIX-INFO] Calato, P, Meyer, J, Quittek, J, "Information 
              Model for IP Flow Information Export" draft-ietf-ipfix-
              info-04, November 2003 
       
           [ClPB93] K.C. Claffy, G.C. Polyzos, H.-W. Braun, Application 
              of Sampling Methodologies to Network Traffic 
              Characterization, Proceedings of ACM SIGCOMM'93, San 
              Francisco, CA, USA, September 13-17, 1993 
        
           [IPFIX-PROTO]   B. Claise,  B. Stewart, G. Sadasivan, M. 
              Fullmer,P. Calato , R. Penno, IPFIX Protocol 
              Specifications , Internet Draft, draft-ietf-ipfix-
              protocol-05.txt, August 2004. 
            
           [RFC-2460] S. Deering, R. Hinden, Internet Protocol, Version 
              6 (IPv6) Specification, RFC 2460, December 1998. 
            
           [DuGr01] N. G. Duffield and M. Grossglauser, Trajectory 
              Sampling for Direct Traffic Observation, IEEE/ACM Trans. 
              on Networking, 9(3), 280-292, June 2001. 
            
           [DuGeGr02] N.G. Duffield, A. Gerber, M. Grossglauser, 
              Trajectory Engine: A Backend for Trajectory Sampling, 
              IEEE Network Operations and Management Symposium 2002, 
              Florence, Italy, April 15-19, 2002. 
            
           [DuGr04] N. G. Duffield and M. Grossglauser, Trajectory 
              Sampling with Unreliable Reporting, Proc IEEE Infocom 
              2004, Hong Kong, March 2004, 
            
            
           [RFC-2914] S. Floyd, Congestion Control Principles, RFC 
              2914, September 2000. 
               
               

    
   Duffield (Ed.)            Expires March 2005                [Page 28] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
           [RFC-2804] IAB and IESG, Network Working Group, IETF Policy 
              on Wiretapping, RFC 2804, May 2000 
            
           [RFC-1213] - K. McCloghrie, M. Rose, Management Information 
              Base for Network Management of TCP/IP-based 
              internets:MIB-II, RFC 1213, March 1991. 
            
            
           [RFC-3176] P. Phaal, S. Panchen, N. McKee, InMon 
              Corporation's sFlow: A Method for Monitoring Traffic in 
              Switched and Routed Networks, RFC 3176, September 2001 
            
           [RFC-2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, 
              Framework for IP Performance Metrics, RFC 2330, May 1998 
            
           [RFC-791] J. Postel, "Internet Protocol", STD 5, RFC 791, 
              September 1981. 
            
           [UDP]  Postel, J., "User Datagram Protocol" RFC 768, August 
              1980 
    
           [IPFIX-REQUIRE] J. Quittek, T. Zseby, B. Claise, S. Zander, 
              Requirements for IP Flow Information Export, Internet 
              Draft draft-ietf-ipfix-reqs-16.txt, work in progress, 
              June 2004. 
            
           [RFC1771]   Rekhter, Y. and T. Li, "A Border Gateway 
              Protocol 4 (BGP-4)", RFC 1771, March 1995. 
                   
           [RFC-3031]  Rosen, E., Viswanathan, A. and R. Callon, 
              "Multiprotocol Label Switching Architecture", RFC 3031, 
              January 2001. 
            
           [SPSJTKS01] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. 
              E. Jones, F. Tchakountio, S. T. Kent, W. T. Strayer, 
              Hash-Based IP Traceback, Proc. ACM SIGCOMM 2001, San 
              Diego, CA, September 2001. 
            
           [RFC-2960] R. Stewart, (ed.) "Stream Control Transmission 
              Protocol", RFC 2960, October 2000. 
            
           [RFC-3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. 
              Conrad, "SCTP Partial Reliability Extension", RFC 3758, 
              May 2004. 
            
           [Zs02] T. Zseby, ``Deployment of Sampling Methods for SLA 
              Validation with Non-Intrusive Measurements'', Proceedings 
              of Passive and Active Measurement Workshop (PAM 2002), 
              Fort Collins, CO, USA, March 25-26, 2002  
       
   15.       Authors' Addresses 
       
    
   Duffield (Ed.)            Expires March 2005                [Page 29] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
         Derek Chiou 
         Avici Systems 
         101 Billerica Ave 
         North Billerica, MA 01862 
         Phone: +1 978-964-2017 
         Email: dchiou@avici.com 
       
         Benoit Claise 
         Cisco Systems 
         De Kleetlaan 6a b1 
         1831 Diegem 
         Belgium 
         Phone: +32 2 704 5622 
         Email: bclaise@cisco.com 
       
         Nick Duffield 
         AT&T Labs - Research 
         Room B-139 
         180 Park Ave 
         Florham Park NJ 07932, USA 
         Phone: +1 973-360-8726 
         Email: duffield@research.att.com 
       
         Albert Greenberg 
         AT&T Labs - Research 
         Room A-161 
         180 Park Ave 
         Florham Park NJ 07932, USA 
         Phone: +1 973-360-8730 
         Email: albert@research.att.com 
       
         Matthias Grossglauser 
         School of Computer and Communication Sciences 
         EPFL 
         1015 Lausanne 
         Switzerland 
         Email: matthias.grossglauser@epfl.ch 
       
         Peram Marimuthu 
         Cisco Systems 
         170, W. Tasman Drive 
         San Jose, CA 95134 
         Phone: (408) 527-6314 
         Email: peram@cisco.com 
       
         Jennifer Rexford 
         AT&T Labs - Research 
         Room A-169 
         180 Park Ave 
         Florham Park NJ 07932, USA 
         Phone: +1 973-360-8728 
         Email: jrex@research.att.com 
    
   Duffield (Ed.)            Expires March 2005                [Page 30] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
        
         Ganesh Sadasivan  
         Cisco Systems  
         170 W. Tasman Drive  
         San Jose, CA 95134  
         Phone: (408) 527-0251  
         Email: gsadasiv@cisco.com 
       
   16.       Intellectual Property Statements 
       
      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 
      RFC 3668. 
       
      The IETF has been notified by AT&T Corp. of intellectual property 
      rights claimed in regard to some or all of the specification 
      contained in this document. For more information, see  
      http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-
      framework.txt 
    
      The IETF has been notified by Cisco Corp. of intellectual 
      property rights claimed in regard to some or all of the 
      specification contained in this document. For more information, 
      see  
      http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-
      protocol.txt 
       
   17.       Full Copyright Statement 
       
      Copyright (C) The Internet Society (2004).  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 translations of it may be copied and furnished 
      to others, and derivative works that comment on or otherwise 
      explain it or assist in its implementation may be prepared, 
      copied, published and distributed, in whole or in part, without 
      restriction of any kind, provided that the above copyright notice 
      and this paragraph are included on all such copies and derivative 
      works. However, this document itself may not be modified in any 
      way, such as by removing the copyright notice or references to 
      the Internet Society or other Internet organizations, except as 
      needed for the purpose of developing Internet standards in which 
      case the procedures for copyrights defined in the Internet 
      Standards process must be followed, or as required to translate 
      it into languages other than English. 
       
      The limited permissions granted above are perpetual and will not 
      be revoked by the Internet Society or its successors or assigns. 
    
   Duffield (Ed.)            Expires March 2005                [Page 31] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
    
      This document and the information contained herein is provided on 
      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 
      ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 
      IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 
      OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 
      IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 
      PURPOSE. 
    











































    
   Duffield (Ed.)            Expires March 2005                [Page 32] 
    

--------------020900030702040403060700
Content-Type: text/html;
 name="diff-07-08.html"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="diff-07-08.html"
Content-Transfer-Encoding: 8bit



    
                                                                         
   Internet Draft                               Nick Duffield (Editor) 
   Category: Informational                        AT&T Labs û – Research 
   Document: <draft-ietf-psamp-framework-07.txt>           August <draft-psamp-framework-08.txt>             September 2004 
   Expires: February March 2005                                                   
                                                                         
                                                                         
                                                                         
    
    
               A Framework for Packet Selection and Reporting 
    
    
   Status of this Memo 
    
      This document is an Internet-Draft and is in full conformance 
      with all provisions of Section 10 of RFC 2026.  
       
      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. 
       
   Abstract 
       
      This document specifies a framework for the PSAMP (Packet 
      Sampling) 
      SAMPling) protocol. The functions of this protocol are to select 
      packets from a stream according to a set of standardized reports, 
      selectors, to form a stream of reports on the selected packets, 
      and to export 
      that stream the reports to a collector. This framework details 
      the components of this architecture, then describes some generic 
      requirements, motivated the dual aims of ubiquitous deployment 
      and utility of the reports for applications. Detailed 
      requirements for selection, reporting and export exporting  processes 
      are described, along with configuration requirements of the PSAMP 
      functions. 
    
      Comments on this document should be addressed to the PSAMP 
      Working Group mailing list: psamp@ops.ietf.org 
       
      To subscribe: psamp-request@ops.ietf.org, in body: subscribe 
      Archive: https://ops.ietf.org/lists/psamp/ 
       
    
   Duffield (Ed.)            Expires February March 2005                 [Page 1] 
   Internet Draft      Packet Selection and Reporting        August     September 2004 
    
    
   Table of Contents 
    
      1.   Introduction...............................................3 
      2.   PSAMP Documents Overview....................................3 
      2.   Introduction................................................4 Overview...................................4 
      3.   Elements, Terminology and Architecture......................5 High-level Architecture..........4 
      3.1  High-level description of the PSAMP Architecture............5 Architecture ..........4 
      3.2  Observation Points, Packet Streams and Packet Content.......5 Content......5 
      3.3  Selection Process...........................................6 Process .........................................6 
      3.4  Reporting Process...........................................8 Process .........................................7 
      3.5  Measurement Process.........................................8 Process........................................8 
      3.6  Exporting Process...........................................8 Process .........................................8 
      3.7  PSAMP Device................................................9 Device...............................................8 
      3.8  Collector...................................................9  Collector..................................................8 
      3.9  Possible configurations.....................................9 Configurations....................................9 
      3.10 PSAMP and IPFIX Interaction................................10 Interaction................................9 
      4.   Generic Requirements for PSAMP.............................10 PSAMP.............................9 
      4.1  Generic Selection Process Requirements.....................10 Requirements....................10 
      4.2  Generic Reporting Process Requirements.....................11 Requirements....................10 
      4.3  Generic Export Process Requirements........................11 Exporting process Requirements....................11 
      4.4  Generic Configuration Requirements.........................12 Requirements........................11 
      5.   Packet Selection Operations................................12 Operations...............................12 
      5.1  Two Types of Selection Operation...........................12 Operation..........................12 
      5.2  PSAMP Packet Selection Operations..........................13 Operations ........................12 
      5.3  Selection Rate Terminology.................................15 Terminology................................14 
      5.4  Input Sequence Numbers for Primitive Selection Processes...15 Processes..15 
      5.5  Composite Selectors........................................16 Selectors.......................................15 
      5.6  Constraints on the Sampling Frequency......................16 Frequency.....................16 
      6.   Reporting Process..........................................17 Process ........................................16 
      6.1  Mandatory Contents of Packet Reports.......................17 Reports......................16 
      6.2  Extended Packet Reports....................................17 Reports...................................17 
      6.3  Extended Packet Reports in the Presence of IPFIX...........18 IPFIX .........17 
      6.4  Report Interpretation......................................18 Interpretation.....................................17 
      6.5  Report Timeliness..........................................19  Export Packet Compression ................................18 
      7.   Parallel Measurement Processes.............................20 Processes............................18 
      8.   Export Process.............................................20   Exporting Process ........................................19 
      8.1  Use of IPFIX...............................................20 IPFIX..............................................19 
      8.2  Congestion-aware Unreliable Transport......................21 Transport.....................19 
      8.3  Limiting Delay for Export Packets..........................21 Packets ........................19 
      8.4  Configurable Export Rate Limit.............................21 Limit............................21 
      8.5  Collector Destination......................................22 Destination.....................................21 
      8.6  Local Export...............................................22 Export..............................................21 
      9.   Configuration and Management...............................22 Management..............................21 
      10.  Feasibility and Complexity.................................23 Complexity................................22 
      10.1 Feasibility................................................23 Feasibility...............................................22 
      10.1.1 Filtering................................................23 Filtering...............................................22 
      10.1.2 Sampling.................................................23 Sampling ...............................................22 
      10.1.3 Hashing..................................................23 Hashing.................................................23 
      10.1.4 Reporting...............................................23 
      10.1.5 Export..................................................23 
      10.2 Potential Hardware Complexity.............................23 
      11.  Applications..............................................24 
      11.1 Baseline Measurement and Drill Down.......................25 
    
   Duffield (Ed.)            Expires February March 2005                 [Page 2] 
    
   Internet Draft      Packet Selection and Reporting        August     September 2004 
    
    
      10.1.4 Reporting................................................24 
      10.1.5 Export...................................................24 
      10.2 Potential Hardware Complexity..............................24 
      11.  Applications...............................................25 
      11.1 Baseline Measurement and Drill Down........................25 
    
    
      11.2 Trajectory Sampling........................................26 Sampling.......................................25 
      11.3 Passive Performance Measurement............................26 Measurement...........................25 
      11.4 Troubleshooting............................................27 Troubleshooting...........................................26 
      12.  Security Considerations....................................28 Considerations...................................27 
      13.  Normative References.......................................28 References......................................27 
      14.  Informative References.....................................28 References....................................28 
      15.  Authors' Addresses.........................................30 Addresses........................................29 
      16.  Intellectual Property Statements...........................31 Statements..........................31 
      17.  Full Copyright Statement...................................32 Statement..................................31 
   
                                                               
      Copyright (C) The Internet Society (2004).  All Rights Reserved. 
      This document is an Internet-Draft and is in full conformance 
      with all provisions of Section 10 of RFC 2026. 
       
      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. 
          
      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. 
       
   1. PSAMP Documents Overview 
       
       
      The PSAMP protocol specifies how network elements are to sample 
      or otherwise select a subset of packets passing through them, and 
      how reports on the selected packets are to be exported. The 
      following documents will describe the PSAMP protocol. 
       
    
   Duffield (Ed.)          Expires February 2005                [Page 3] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
    
    
      PSAMP-FRAMEWORK: ôA Framework for Packet Selection and 
      Reportingö: this document. This framework document is for 
      informational purposes; the normative references for PSAMP are 
      the four documents listed below [PSAMP-TECH], [PSAMP-MIB], 
      [PSAMP-PROTO], [PSAMP-INFO]. Definitions of terminology and the 
      use of the terms ômustö, ôshouldö and ômayö in this document are 
      informational only. 
       
      [PSAMP-TECH]: ôSampling and Filtering Techniques for IP Packet 
      Selectionö, describes the set of packet selection techniques 
      supported by PSAMP. 
       
      [PSAMP-MIB]: ôDefinitions of Managed Objects for Packet Samplingö 
      describes the PSAMP Management Information Base  
       
      [PSAMP-PROTO]: ôPacket Sampling (PSAMP) Protocol Specificationsö 
      specifies the export of packet information from a PSAMP Exporting 
      Process to a PSAMP Colleting Process 
          
      [PSAMP-INFO]: ôInformation Model for Packet Sampling Exportsö 
      defines an information and data model for PSAMP. 
           
       
   2. Introduction 
       
      This document describes the PSAMP framework for network elements 
      to select subsets of packets by statistical and other methods, 
      and to export a stream of reports on the selected packets to a 
      collector.  
       
      The motivation to codify for the PSAMP standard comes from the need for 
      measurement-based support for network management and control 
      across multivendor domains. This requires domain wide consistency 
      in the types of selection schemes available, the manner in which 
      the resulting measurements are presented, and consequently, 
      consistency of the interpretation that can be put on them. 
       

    
   Duffield (Ed.)            Expires March 2005                 [Page 3] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      The motivation for specific packet selection operations comes 
      from the applications that they enable. Development of the PSAMP 
      standard is open to influence by the requirements of standards in 
      related IETF Working Groups, for example, IP Performance Metrics 
      (IPPM) [RFC-2330] and Internet Traffic Engineering (TEWG).  
       
      The name PSAMP is a contraction of the phrase Packet Sampling. 
      The word ôsamplingö “sampling” captures the idea that only a subset of all 
      packets passing a network element will be selected for reporting. 
      But PSAMP selection operations include random selection, 
      deterministic selection (filtering), and deterministic 
      approximations to random selection (hash-based selection). 
       
       
    
   Duffield (Ed.)          Expires February 2005                [Page 4] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
       
   2. PSAMP Documents Overview 
    
      PSAMP-FRAMEWORK: “A Framework for Packet Selection and 
      Reporting”: this document. This document describes the PSAMP 
      framework for network elements to select subsets of packets by 
      statistical and other methods, and to export a stream of reports 
      on the selected packets to a collector. Definitions of 
      terminology and the use of the terms “must”, “should” and “may” 
      in this document are informational only. 
       
      [PSAMP-TECH]: “Sampling and Filtering Techniques for IP Packet 
      Selection”, describes the set of packet selection techniques 
      supported by PSAMP. 
       
      [PSAMP-MIB]: “Definitions of Managed Objects for Packet Sampling” 
      describes the PSAMP Management Information Base  
       
      [PSAMP-PROTO]: “Packet Sampling (PSAMP) Protocol Specifications” 
      specifies the export of packet information from a PSAMP Exporting 
      Process to a PSAMP Colleting Process 
          
      [PSAMP-INFO]: “Information Model for Packet Sampling Exports” 
      defines an information and data model for PSAMP. 
       
   3. Elements, Terminology and High-level Architecture 
       
   3.1 High-level description of the PSAMP Architecture 
       
      Here is an informal high level description of the PSAMP protocol 
      operating in a PSAMP device (all terms will be defined 
      presently). A stream of packets is observed at an observation 
      point. A selection process inspects each packet to determine 
      whether it should be selected. A reporting process constructs a 
      report on each selected packet, using the packet content, and 
      possibly other information such as the packet treatment or the 
      arrival timestamps. timestamp. An exporting process sends the reports to a 
      collector, together with any subsidiary information needed for 
      their interpretation.  
    
   Duffield (Ed.)            Expires March 2005                 [Page 4] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
    
      The following figure indicates the sequence of the three process, 
      selection, 
      processes (selection, reporting, and exporting, exporting) within the PSAMP 
      device. The composition of the selection process followed by the 
      reporting process is known as the measurement process. 
       
                 +---------+    +---------+    +---------+ 
       Packet 
       Observed  |Selection|    |Reporting|    |Exporting| 
       Stream--->|Process 
       Packet--->|Process  |--->|Process  |--->|Process  |--->Collector   
       Stream    +---------+    +---------+    +---------+  
               \----Measurement Process-----/                         
    
      The following sections give the detailed definitions of each of 
      all the objects just named. 
    
   3.2 Observation Points, Packet Streams and Packet Content 
       
      This section contains the definition of terms relevant to 
      obtaining the packet input to the selection process.  
       
      * Observation Point  
       
        An observation point is a location in the network where packets 
        can be observed. Examples include: 
         
             (i) a line to which a probe is attached; 
             (ii) a shared medium, such as an Ethernet-based LAN; 
             (iii) a single port of a router, or set of interfaces 
             (physical or logical) of a router; 
             (iv) an embedded measurement subsystem within an 
        interface. 
              
        Note that one observation point may be a superset of several 
        other observation points.  For example one observation point 
    
   Duffield (Ed.)          Expires February 2005                [Page 5] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
        can be an entire line card.  This would be the superset of the 
        individual observation points at the line card's interfaces. 
       
      * Observed Packet Stream. Stream 
         
        The observed packet stream is the set of all packets observed 
        at the observation point. 
       
      * Packet Stream 
    
        A packet stream denotes a subset of the observed packet stream. 
         
      * Packet Content 
       
        The packet content denotes he the union of the packet header 
        (which includes link layer, network layer and other 
        encapsulation headers) and the packet payload. 

    
   Duffield (Ed.)            Expires March 2005                 [Page 5] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
       
      Note that packets selected from a stream, e.g. by sampling, do 
      not necessarily possess a property by which they can be 
      distinguished from packets that have not been selected. For this 
      reason the term ôstreamö “stream” is favored over ôflowö, “flow”, which is defined 
      as set of packets with common properties [IPFIX-REQUIRE]. 
       
   3.3 Selection Process 
       
      This section defines the selection process and related objects. 
       
      * Selection Process 
         
        A selection process takes a packet stream as its input and 
        selects a subset of that stream as its output. 
         
      * Selection State:  
       
           A selection process may maintain state information for use 
           by the selection process and/or the reporting process. At a 
           given time, the selection state may depend on packets 
           observed at and before that time, and other variables. 
           Examples include: 
             
                  (i) sequence numbers of packets at the input of 
                  selectors; 
                   
                  (ii) a timestamp of observation of the packet at the 
                  observation point; 
                   
                  (iii) iterators for pseudorandom number generators; 
    
   Duffield (Ed.)          Expires February 2005                [Page 6] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
                
                  (iv) hash values calculated during selection; 
             
                  (v) indicators of whether the packet was selected by 
                  a given selector; 
                   
           Selection processes may change portions of the selection 
           state as a result of processing a packet. Selection state 
           for a packet is to reflect the state after processing the 
           packet. 
            
      * Selector:  
       
           A selector defines the action of a selection process on a 
           single packet of its input. A selected packet becomes an 
           element of the output packet stream of the selection 
           process. 
            
           The selector can make use of the following information in 
           determining whether a packet is selected: 
            
    
   Duffield (Ed.)            Expires March 2005                 [Page 6] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
           (i) the packetÆs packet’s content; 
       
           (ii) information derived from the packet's treatment at the     
           observation point; 
       
           (iii) any selection state that may be maintained by the 
           selection process. 
            
      * Composite Selection Process:               
         
           A composite selection process is an ordered composition of 
           selection processes, in which the output stream issuing from 
           one component forms the input stream for the succeeding 
           component.  
            
      * Composite Selector:  
         
           A selector is composite if it defines a composite selection 
           process. 
    
      * Primitive Selection Process:  
       
           A selection process is primitive if it is not a composite a 
           selection process. 
            
      * Primitive Selector:  
       
           A selector is primitive if it defines a primitive selection 
           process. 
            
    
   Duffield (Ed.)          Expires February 2005                [Page 7] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
            
   3.4 Reporting Process 
       
      * Reporting Process:  
       
           A reporting process creates a report stream on packets 
           selected by a selection process, in preparation for export. 
           The input to the reporting process comprises that 
           information available to the selection process per selected 
           packet, specifically: 
            
             (i) the selected packetÆs packet’s content; 
              
             (ii) information derived from the selected packet's 
             treatment at the observation point; 
              
             (iii) any selection state maintained by the inputting 
             selection process, reflecting any modifications to the 
             selection state made during selection of the packet. 
              
      * Packet Reports:  
            

    
   Duffield (Ed.)            Expires March 2005                 [Page 7] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
           Packet reports comprise a configurable subset of a packetÆs packet’s 
           input to the reporting process, including the packetÆs packet’s 
           content, information relating to its treatment, treatment  
           (for example, the output interface), and its associated 
           selection state. state (for example, a hash of the packet’s 
           content) 
    
      * Report Interpretation:  
            
           Report interpretation comprises subsidiary information, 
           relating to one or more packets, that is used for 
           interpretation of their packet reports. Examples include 
           configuration parameters of the selection process and of the 
           reporting process. 
    
      * Report Stream: 
            
           The report stream is the output of a reporting process, 
           comprising two distinguished types of information: packet 
           reports, and report interpretation. 
              
   3.5 Measurement Process 
    
      * A Measurement Process is the composition of a selection process 
        that takes the observed packet stream as its input, followed by 
        a reporting process. 
       
   3.6 Exporting Process 
       
      * Exporting Process:  


    
   Duffield (Ed.)          Expires February 2005                [Page 8] 
    
   Internet Draft      Packet Selection and Reporting        August 2004  
         
        An exporting process sends sends, in the form of export packet, the 
        output of one or more measurement processes to one or more 
        collectors.  
    
      * Export Packets:  
         
        a combination of report interpretation and/or one or more 
        packet reports, and perhaps report interpretation, reports are bundled by the export exporting process into a 
        export packet for 
        export exporting to a collector. 
         
   3.7 PSAMP Device 
       
      A PSAMP Device is a device hosting at least a PSAMP an observation point, 
      a measurement process and an exporting process. Typically, 
      corresponding observation point(s), measurement process(es) and 
      exporting process(es) are co-located at this device, for example 
      at a router. 
       
   3.8 Collector 
       

    
   Duffield (Ed.)            Expires March 2005                 [Page 8] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      A collector receives a report stream exported by one or more 
      export 
      exporting processes. In some cases, the host of the measurement 
      and/or export exporting processes may also serve as the collector. 
    
   3.9 Possible configurations Configurations 
        
      Various possibilities for the high level architecture of these 
      elements are as follows. 
       
          MP = Measurement Process, EP = Export Process Exporting process 
       
          PSAMP Device 
         +---------------------+                 +------------------+ 
         |Observation Point(s) |                 | Collector(1)     | 
         |MP(s)--->EP----------+---------------->|                  |     
         |MP(s)--->EP----------+-------+-------->|                  | 
         +---------------------+       |         +------------------+ 
                                       | 
          PSAMP Device                 |     
         +---------------------+       |         +------------------+ 
         |Observation Point(s) |       +-------->| Collector(2)     | 
         |MP(s)--->EP----------+---------------->|                  | 
         +---------------------+                 +------------------+ 
             
          PSAMP Device                              
         +---------------------+          
         |Observation Point(s) |          
         |MP(s)--->EP---+      |          
         |              |      |          
         |Collector(3)<-+      | 
         +---------------------+   
       

    
   Duffield (Ed.)          Expires February 2005                [Page 9] 
    
   Internet Draft      Packet Selection and Reporting        August 2004   
       
   3.10    PSAMP and IPFIX Interaction 
       
      The PSAMP measurement process can be viewed as analogous to the 
      IPFIX metering process. The PSAMP measurement process takes an 
      observed packet stream as its input, and produces packet reports 
      as its output. The IPFIX metering process produces flow records 
      as its output. The distinct name ômeasurement processö “measurement process” has been 
      retained in order to avoid potential confusion in settings where 
      IPFIX and PSAMP coexist, and in order to avoid the implicit 
      requirement that the PSAMP version satisfy the requirements of an 
      IPFIX metering  process (at least while these are under 
      development). The relationship between PSAMP and IPFIX is 
      described fully more in [PSAMP-INFO].  
    
   4. Generic Requirements for PSAMP 
       
      This section describes the generic requirements for the PSAMP 
      protocol. A number of these are realized as specific requirements 
      in later sections. 
    
    
   Duffield (Ed.)            Expires March 2005                 [Page 9] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
   4.1 Generic Selection Process Requirements. 
       
      * Ubiquity: The selectors must be simple enough to be implemented 
        ubiquitously at maximal line rate. 
       
      * Applicability: the set of selectors must be rich enough to 
        support a range of existing and emerging measurement based 
        applications and protocols. This requires a workable trade-off 
        between the range of traffic engineering applications and 
        operational tasks it enables, and the complexity of the set of 
        capabilities. 
       
      * Extensibility: the protocol must be able to accommodate 
        additional packet selectors not currently defined. 
       
      * Flexibility: the protocol must support selection of packets 
        using various network protocols or encapsulation layers, 
        including Internet Protocol Version 4 (IPv4) [IPv4], Internet 
        Protocol Version 6 (IPv6) [RFC-2460], and Multiprotocol Label 
        Switching (MPLS) [RFC-3031].  
    
      * Robust Selection: packet selection must be robust against 
        attempts to craft an observed packet stream from which packets 
        are selected disproportionately (e.g. to evade selection, or 
        overload measurement systems). 
    


    
   Duffield (Ed.)          Expires February 2005               [Page 10] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
    
      * Parallel Measurement Processes: the protocol must support 
        simultaneous operation of multiple independent measurement 
        processes at the same host. 
       
      * Non-Contingency: the selection decision for each packet must 
        not depend on future packets.   
       
      * Encrypted Packets: selection operations based on interpretation 
        of packet fields must be configurable to ignore (i.e. not 
        select) encrypted packets, when they are detected.  
    
      Selectors are outlined in Section 5, and described in more detail 
      in the companion document [PSAMP-TECH].  
       
   4.2 Generic Reporting Process Requirements 
       
      * Self-defining: the report stream must be complete in the sense 
        that no additional information need be retrieved from the 
        observation point in order to interpret and analyze the 
        reports.   
       
      * Indication of Information Loss: the reports stream must include 
        sufficient information to indicate or allow the detection of 
        loss occurring within the selection, reporting or exporting 
        processes, or in transport. This may be achieved by the use of 
        sequence numbers. 
    
   Duffield (Ed.)            Expires March 2005                [Page 10] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
       
      * Accuracy: the report stream must include information that 
        enables the accuracy of measurements to be determined. 
       
      * Faithfulness: all reported quantities that relate to the packet 
        treatment must reflect the router state and configuration 
        encountered by the packet at the time it is received by the 
        measurement process. 
       
      * Privacy: selection of the content of packet reports will be 
        cognizant of privacy and anonymity issues while being 
        responsive to the needs of measurement applications, and in 
        accordance with [RFC-2804].  Full packet capture of arbitrary 
        packet streams is explicitly out of scope. 
    
      A specific reporting process meeting these requirements, and the 
      requirement for ubiquity, is described in Section 6. 
       
   4.3 Generic Export Process Exporting process Requirements 
       
      * Timeliness: configuration must allow for limiting of buffering 
        delays for the formation and transmission for export reports. 
        See Section 6.5for Error! Reference source not found. for further 
        details. 
       


    
   Duffield (Ed.)          Expires February 2005               [Page 11] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
       
      * Congestion Avoidance: export of a report stream across a 
        network must be congestion avoiding in compliance with [RFC-
        2914]. 
       
      * Secure Export: 
              
        (i) confidentiality: the option to encrypt exported data must 
        be provided. 
     
        (ii) integrity: alterations in transit to exported data must be 
        detectable at the collector 
              
        (iii) authenticity: authenticity of exported data must be 
        verifiable by the collector in order to detect forged data. 
       
      The motivation here is the same as for security in IPFIX export; 
      see Sections 6.3 and 10 of [IPFIX-REQUIRE].   
       
   4.4 Generic Configuration Requirements 
       
      * Ease of Configuration: of sampling and export parameters, e.g. 
        for automated remote reconfiguration in response to collected 
        reports. 
       
      * Secure Configuration: the option to configure via protocols 
        that prevent unauthorized reconfiguration or eavesdropping on 
        configuration communications must be available.  Eavesdropping 
    
   Duffield (Ed.)            Expires March 2005                [Page 11] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
        on configuration might allow an attacker to gain knowledge that 
        would be helpful in crafting a packet stream to evade 
        subversion, or overload the measurement infrastructure. 
    
      Configuration is discussed in Section 9. Feasibility and 
      complexity of PSAMP operations is discussed in Section 10. 
    
   5. Packet Selection Operations 
       
   5.1 Two Types of Selection Operation 
    
      PSAMP categorizes selection operations into two types: 
       
      * Filtering: a filter is a selection operation that selects a 
        packet deterministically based on the packet content, its 
        treatment, and functions of these occurring in the selection 
        state. Two examples are: 
       
           (i) Mask/match filtering.  
              
           (ii) Hash-based selection: a hash function is applied to the 
             packet content, and the packet is selected if the result 
             falls in a specified range. 
       
 

   
   Duffield (Ed.)          Expires February 2005               [Page 12] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
       
      * Sampling: a selection operation that is not a filter is called 
        a sampling operation. This reflects the intuitive notion that 
        if the selection of a packet cannot be determined from its 
        content alone, there must be some type of sampling taking 
        place.  
         
        Sampling operations can be divided into two subtypes: 
    
           (i) Content-independent Sampling, which does not use packet 
             content in reaching sampling decisions. Examples include 
             periodic sampling, and uniform pseudorandom sampling 
             driven by a pseudorandom number whose generation is 
             independent of packet content. Note that in content-
             independent sampling it is not necessary to access the 
             packet content in order to make the selection decision. 
       
           (ii) Content-dependent Sampling, in which the packet content is 
             used in reaching selection decisions decisions. Examples include 
             pseudorandom selection according to a probability that 
             depends on the contents of a packet field; note that this 
             is not a filter. 
       
   5.2 PSAMP Packet Selection Operations 
       
      A spectrum of packet selection operations is described in detail 
      in [PSAMP-TECH]. Here we only briefly summarize the meanings for 
      completeness. 
    
    
   Duffield (Ed.)            Expires March 2005                [Page 12] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      A PSAMP selection process must support at least one of the 
      following selectors. 
          
      * Systematic Time Based Sampling: packet selection is triggered 
        at periodic instants separated by a time called the spacing. 
        All packets that arrive within a certain time of the trigger 
        (called the interval length) are selected. 
       
      * Systematic Count Based Sampling: similar to systematic time 
        based expect that selection is reckoned with respect to packet 
        count rather than time. Packet selection is triggered 
        periodically by packet count, a number of successive packets 
        being selected subsequent to each trigger. 
       
      * Uniform Probabilistic Sampling: packets are selected 
        independently with fixed sampling probability p. 
       
      * Non-uniform Probabilistic Sampling: packets are selected 
        independently with probability p that depends on packet 
        content. 
       
      * Probabilistic n-out-of-N Sampling: form each count-based 
        successive block of N packets, n are selected at random  
    
   Duffield (Ed.)          Expires February 2005               [Page 13] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 random.  
       
      * Mask/match Filtering: this entails taking the masking portions 
        of the packet (i.e. taking the bitwise AND logical “and” with a binary 
        mask) and selecting the packet if the result falls in a range 
        specified in the selection parameters of the filter.  This 
        specification does not preclude the future definition of a high 
        level syntax for defining filtering in a concise way (e.g. TCP 
        port taking a particular value) providing that syntax can be 
        compiled into the bitwise expression. 
         
        Mask/match operations should be available for different 
        protocol portions of the packet header: 
    
           (i) the IP header (excluding options in IPv4, stacked 
           headers in IPv6) 
            
           (ii) transport header 
            
           (iii) encapsulation headers (e.g. the MPLS label stack) if 
           present) 
         
        When the host of a selection process PSAMP device offers mask/match filtering, and, in its 
        usual capacity other than in performing PSAMP functions, 
        identifies or processes information from one or more of the 
        above protocols, then the information should be made available 
        for filtering. For example, when a host PSAMP device routes based on 
        destination IP address, that field should be made available for 
        filtering. Conversely, a host PSAMP device that does not route is 
        not expected to be able to locate an IP address within a 
    
   Duffield (Ed.)            Expires March 2005                [Page 13] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
        packet, or make it available for filtering, although it may do 
        so. 
         
        Since packet encryption alters the meaning of encrypted fields, 
        Mask/Match filtering must be configurable to ignore encrypted 
        packets, when detected. 
       
        Hash-based Selection: Hash-based selection will employ one or 
        more hash functions to be standardized.  A hash function is 
        applied to a subset of packet content, and the packet is 
        selected of the resulting hash falls in a specified range. With 
        a suitable hash function, hash based selection approximates 
        uniform random sampling. Applications of hash-based sampling 
        are described in Section 11.  
         
      * Router State Filtering: the selection process may support 
        filtering based on the following conditions, which may be 
        combined with the AND, OR logical "and", "or" or NOT "not" operators:  
    
           (i) Ingress interface at which packet arrives equals a 
           specified value 

    
   Duffield (Ed.)          Expires February 2005               [Page 14] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
           (ii) Egress interface to which packet is routed to equals a 
           specified value 
           (iii) Packet violated Access Control List (ACL) on the 
           router 
           (iv) Failed Reverse Path Forwarding (RPF) 
           (v) Failed Resource Reservation (RSVP) 
           (vi) No route found for the packet 
           (vii) Origin Border Gateway Protocol (BGP) Autonomous System 
           (AS) equals a specified value or lies within a given range 
           (viii) Destination BGP AS equals a specified value or lies 
           within a given range 
    
       Router architectural considerations may preclude some 
       information concerning the packet treatment, e.g. routing state, 
       being available at line rate for selection of packets. However, 
       if selection not based on routing state has reduced down from 
       line rate, subselection based on routing state may be feasible. 
       
       This section detailed specific requirements for the selection 
       process, motivated by the generic requirement of Section 3.3. 
    
   5.3 Selection Rate Terminology 
       
      The proportion of packets that are selected by a selection 
      operation is figured in two ways: 
       
      * Attained Selection Frequency: the actual frequency with which 
        packets are selected by a selection process. When packets are 
        selected from a set of packets in a stream, the attained 
        sampling frequency is calculated as ratio of the number of 
        packets selected to the number of packets in the set.  
    
   Duffield (Ed.)            Expires March 2005                [Page 14] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
       
      * Target Selection Frequency: the average frequency with which 
        packets are expected to be selected, based on selector 
        parameter settings.  
         
        For sampling operations, due to the inherent statistical 
        variability of sampling decisions, the target and attained 
        selection frequencies will not in general be equal, although 
        they may be close in some circumstances, e.g., when the 
        population size is large.  
    
   5.4 Input Sequence Numbers for Primitive Selection Processes. Processes 
         
      Each instance of a primitive selection process must maintain a 
      count of packets presented at its input. The counter value is to 
      be included as a sequence number for selected packets. The 
      sequence numbers are considered as part of the packet's selection 
      state. 
       
    
   Duffield (Ed.)          Expires February 2005               [Page 15] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
       
      Use of input sequence numbers enables applications to determine 
      the attained selection frequency, and hence correctly normalize 
      network usage estimates regardless of loss of information, 
      regardless of whether this loss occurs because of discard of 
      packet reports in the measurement or reporting process (e.g. due 
      to resource contention in the host of these processes), or loss 
      of export packets in transmission or collection. See [RFC-3176] 
      for further details. 
       
      As an example, consider a set of n consecutive packet reports r1, 
      r2,... , rn, selected by a sampling operation and received at a 
      collector. Let s1, s2,..., sn be the input sequence numbers 
      reported by the packets. The attained selection frequency, taking 
      into account both packet sampling at the observation point and 
      selection arising from loss in transmission, is R = (n-1)/(sn-
      s1). (Note R would be 1 if all packets were selected and there 
      were no transmission loss). 
       
      The attained selection frequency can be used to estimate the 
      number bytes present in a portion of the observed packet stream. 
      Let b1, b2,..., bn be the bytes reported in each of the packets 
      that reached the collector, and set B = b1+b2+...+bn. Then the 
      total bytes present in packets in the observed packet stream 
      whose input sequence numbers lie between s1 and sn is estimated 
      by B/R, i.e, scaling up the measured bytes through division by 
      the attained selection frequency. 
       
      With composite selectors, and input sequence number must be 
      reported for each selector in the composition. 
    
   5.5 Composite Selectors 
       

    
   Duffield (Ed.)            Expires March 2005                [Page 15] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      The ability to compose selectors in a selection process should be 
      provided. The following combinations appear to be most useful for 
      applications: 
             
      * filtering followed by sampling 
         
      * sampling followed by filtering 
       
      Composite selectors are useful for drill down applications. The 
      first component of a composite selector can be used to reduce the 
      load on the second component. In this setting, the advantage to 
      be gained from a given ordering can depend on the composition of 
      the packet stream. 
       
   5.6 Constraints on the Sampling Frequency 
    
      Sampling at full line rate, i.e. with probability 1, is not 
      excluded in principle, although resource constraints may not 
      support it in practice. 
    
   Duffield (Ed.)          Expires February 2005               [Page 16] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
       
   6. Reporting Process 
       
      This section detailed specific requirements for the reporting 
      process, motivated by the generic requirement of Section 3.4 
       
   6.1 Mandatory Contents of Packet Reports 
       
      The reporting process must include the following in each packet 
      report: 
       
           (i) the input sequence number(s) of any sampling operation 
             that acted on the packet in the instance of a measurement 
             process of which the reporting process is a component. 
       
      The reporting process must support inclusion of the following in 
      each packet, packet report, as a configurable option: 
       
           (ii) a basic report on the packet, i.e., some number of 
           contiguous bytes from the start of the packet, including the 
           packet header (which includes link layer, network layer and 
           other encapsulation headers) and some subsequent bytes of 
           the packet payload. 
            
      Some devices hosting reporting processes may not have the 
      resource capacity or functionality to provide more detailed 
      packet reports that those in (i) and (ii) above. Using this 
      minimum required reporting functionality, the reporting process 
      places the burden of interpretation on the collector, or on 
      applications that it supplies. Some devices may have the 
      capability to provide extended packet reports, described in the 
      next section.  
    
    
   Duffield (Ed.)            Expires March 2005                [Page 16] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
   6.2 Extended Packet Reports 
    
      The reporting process may support inclusion in packet reports of 
      the following information, inclusion any or all being 
      configurable as an option. 
       
           (iii) fields relating to the following protocols used in the 
           packet:: 
           packet: IPv4, IPV6, transport protocols, MPLS. 
             
           (iv) packet treatment, including: 
       
            - identifiers for any input and output interfaces of the 
           observation point that were traversed by the packet 
             
            - source and destination BGP AS 
       
    
   Duffield (Ed.)          Expires February 2005               [Page 17] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
       
           (v) selection state associated with the packet, including: 
       
           - the timestamp of observation of the packet at the 
           observation point. The timestamp should be reported to 
           microsecond resolution.  
       
           - hashes, where calculated. 
       
       It is envisaged that selection of fields for extended packet 
       reporting may be used to reduce reporting bandwidth, in which 
       case the option to report information in (ii) may not be 
       exercised. 
    
   6.3 Extended Packet Reports in the Presence of IPFIX 
       
      If an IPFIX metering process is supported at the observation 
      point, then in order to be PSAMP compliant, extended packet 
      reports must be able to include all fields required in the IPFIX 
      information model [IPFIX-REQUIRE], [IPFIX-INFO], with modifications appropriate to 
      reporting on single packets rather than flows. 
    
   6.4  Report Interpretation 
    
      Information for use in report interpretation must include  
       
           (i) configuration parameters of the selectors of the packets 
           reported on.  
            
           (ii) format of the packet report; 
            
           (iii) indication of the inherent accuracy of the reported 
           quantities, e.g., of the packet timestamp.  
            
           (iv) identifiers for observation point, measurement process, 
           and export exporting process.  
    
    
   Duffield (Ed.)            Expires March 2005                [Page 17] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      The accuracy measure in (iii) is of fundamental importance for 
      estimating the likely error attached to estimates formed from the 
      packet reports by applications. 
       
      Identifiers in (iv) are necessary, e.g., in order to match packet 
      reports to the selection process that selected them. For example, 
      when packet reports due to a sampling operation suffer loss 
      (either during export, or in transit) it may be desirable to 
      reconfigure downwards the sampling rate on the selection process 
      that selected them.  
       
      The requirements for robustness and transparency are motivations 
      for including report interpretation in the report stream. 
      Inclusion makes the report stream self-defining.  The PSAMP 
      framework excludes reliance on an alternative model in which 
    
   Duffield (Ed.)          Expires February 2005               [Page 18] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
      interpretation is recovered out of band. This latter approach is 
      not robust with respect to undocumented changes in selector 
      configuration, and may give rise to future architectural problems 
      for network management systems to coherently manage both 
      configuration and data collection. 
       
      It is not envisaged that all report interpretation be included in 
      every packet report. Many of the quantities listed above are 
      expected to be relatively static; they could be communicated 
      periodically, and upon change. 
    
   6.5 Export Packet Compression 
       
      To conserve network bandwidth and resources at the collector, the 
      export packets may be compressed before export.  Compression is 
      expected to be quite effective since the sampled packets may 
      share many fields in common, e.g. if a filter focuses on packets 
      with certain values in particular header fields. Using 
      compression, however, could impact the timeliness of packet 
      reports. Any consequent delay must not violate the timeliness 
      requirement for availability of packet reports at the collector. 
       
   6.5 Report Timeliness 
    
      Low measurement latency allows 
    
   7. Parallel Measurement Processes 
       
      Because of the traffic monitoring system increasing number of distinct measurement 
      applications, with varying requirements, it is desirable to set 
      up parallel measurement processes on given observed packet 
      stream. A device capable of hosting a measurement process should 
      be more responsive able to real-time network events, for example, in 
      quickly identifying sources support more than one independently configurable 
      measurement process simultaneously. Each such measurement process 
      should have the option of congestion. Timeliness is 
      generally a good thing for devices performing being equipped with its own exporting 
      process; otherwise the sampling since 
      it minimizes parallel measurement processes may share 
      the amount same exporting process.  
       
      Each of memory needed to buffer samples. 
       
      Keeping the packet dispatching delay small has other benefits 
      besides limiting buffer requirements. For many applications parallel measurement processes should be independent. 
      However, resource constraints may prevent complete reporting on a 
      resolution of 1 second is sufficient. Applications in 
      packet selected by multiple selection processes. In this 
      category would include: identifying sources associated with 
      congestion; tracing denial of service attacks through the network case, 
    
   Duffield (Ed.)            Expires March 2005                [Page 18] 
    
   Internet Draft      Packet Selection and constructing traffic matrices. Furthermore, keeping dispatch 
      delay within the resolution required by applications eliminates 
      the need for timestamping by synchronized clocks at observation 
      points, or Reporting     September 2004 
    
    
      reporting for the observation points and collector to maintain 
      bi-directional communication in order to track clock offsets. The 
      collector can simply process packet reports in the order must be complete for at least one 
      measurement process; other measurement processes need only record 
      that they are received, using its own clock as a "global" time base. 
      This avoids selected the complexity of buffering and reordering samples. 
      See [DuGeGr02] for an example. 
       
      The delay between observation of a packet and transmission of a 
      export packet containing packet, e.g., by incrementing a report on that packet has several 
      components. counter. 
      The priority amongst measurement processes under resource 
      contention should be configurable. 
       
      It is difficult not proposed to standardize a given numerical 
      delay requirement, since in practice the delay may be sensitive 
      to processor load at the observation point. Therefore, PSAMP aims 
      to control that portion number of parallel 
      measurement processes. 
       
   8. Exporting Process 
       
      This section detailed specific requirements for the delay within the observation point 
      that is due to buffering in exporting 
      process, motivated by the formation and transmission generic requirements of 
      export packets.  
    
    
   Duffield (Ed.)          Expires February 2005               [Page 19] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
    
    
      In order to limit delay in the formation Section 3.6 
       
   8.1 Use of export packets, the 
      export process must provide IPFIX 
       
      PSAMP will use the ability to close out and enqueue IP Flow Information eXport (IPFIX) protocol 
      for transmission any export packet in formation as soon as it 
      includes one packet report. This could be achieved, of the report stream. The IPFIX protocol is well 
      suited for example, 
      by this purpose, because the following means: 
       
          - IPFIX architecture matches 
      the number of packet reports per PSAMP architecture very well and the means provided by the 
      IPFIX protocol are sufficient.  
       
   8.2 Congestion-aware Unreliable Transport 
    
      The export packet is of the report stream does not 
                  to exceed a maximum value, which can be configured to 
                  take require reliable export.  
      Section 5.4 shows that the value 1. 
                   
          - use of input sequence number in packet 
      selectors means that the ability to exclude report interpretation from any estimate traffic rates is not 
      impaired by export loss. Export packet that contains loss becomes another form 
      of sampling, albeit a packet report; 
       
      In order to limit the delay in less desirable, and less controlled, form 
      of sampling. 
       
      On the transmission contrary, retransmission of lost export 
      packets, a configurable upper bound packets consumes 
      additional network resources. The requirement to the delay of store 
      unacknowledged data is an export 
      packet prior impediment to transmission having ubiquitous support 
      for PSAMP. 
       
      In order to jointly satisfy the timeliness and congestion 
      avoidance requirements of Section 4.3, a congestion aware 
      unreliable transport protocol must be provided. If the bound is 
      exceeded the export packet used. IPFIX is dropped. This functionality can be 
      provided by the timed reliability service compatible 
      with this requirement, since it mandates support of the Stream 
      Control Transmission Protocol (SCTP) [SCTP] and the SCTP Partial 
      Reliability Extension [RFC-3758]. 
    
   7. Parallel Measurement Processes 
       
      Because of IPFIX also allows the increasing number use of distinct measurement 
      applications, with varying requirements, 
      User Datagram Protocol (UDP) [UDP] although it is desirable to set 
      up parallel measurement processes on given observed packet 
      stream. A device capable of hosting not a 
      congestion aware protocol. However, in this case, the Export 
      Packets must remain wholly within the administrative domains of 
      the operators [IPFIX-PROTO]. 
       
   8.3 Limiting Delay for Export Packets 
          
      Low measurement process should 
      be able latency allows the traffic monitoring system to support 
      be more than one independently configurable 
      measurement process simultaneously. Each such measurement process 
      should have the option responsive to real-time network events, for example, in 
      quickly identifying sources of being equipped with its own export 
      process; otherwise congestion. Timeliness is 
    
   Duffield (Ed.)            Expires March 2005                [Page 19] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      generally a good thing for devices performing the parallel measurement processes may share sampling since 
      it minimizes the same export process.  
       
      Each amount of memory needed to buffer samples. 
       
      Keeping the parallel measurement processes should be independent. 
      However, resource constraints may prevent complete reporting on a packet selected by multiple selection processes. In dispatching delay small has other benefits 
      besides limiting buffer requirements. For many applications a 
      resolution of 1 second is sufficient. Applications in this case, 
      reporting for 
      category would include: identifying sources associated with 
      congestion; tracing denial of service attacks through the packet must be complete network 
      and constructing traffic matrices. Furthermore, keeping dispatch 
      delay within the resolution required by applications eliminates 
      the need for timestamping by synchronized clocks at least one 
      measurement process; other measurement processes need only record observation 
      points, or for the observation points and collector to maintain 
      bi-directional communication in order to track clock offsets. The 
      collector can simply process packet reports in the order that 
      they selected the packet, e.g., by incrementing are received, using its own clock as a counter. "global" time base. 
      This avoids the complexity of buffering and reordering samples. 
      See [DuGeGr02] for an example. 
       
      The priority amongst measurement processes under resource 
      contention should be configurable. delay between observation of a packet and transmission of a 
      export packet containing a report on that packet has several 
      components. It is not proposed difficult to standardize a given numerical 
      delay requirement, since in practice the number of parallel 
      measurement processes. 
       
   8. Export Process 
       
      This section detailed specific requirements for the exporting 
      process, motivated by delay may be sensitive 
      to processor load at the generic requirements of Section 3.6 
       
   8.1 Use of IPFIX 
       

    
   Duffield (Ed.)          Expires February 2005               [Page 20] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 observation point. Therefore, PSAMP will use the IP Flow Information eXport (IPFIX) protocol 
      for export aims 
      to control that portion of the report stream. The IPFIX protocol is well 
      suited for this purpose, because delay within the IPFIX architecture matches observation point 
      that is due to buffering in the PSAMP architecture very well formation and the means provided by the 
      IPFIX protocol are sufficient. The remainder transmission of this section 
      describes  
       
   8.2 Congestion-aware Unreliable Transport 
    
      The 
      export of the report stream does not require reliable export.  
      Section 0 shows that packets.  
    
      In order to limit delay in the use formation of input sequence number in packet 
      selectors means that export packets, the 
      exporting process must provide the ability to estimate traffic rates is not 
      impaired by close out and 
      enqueue for transmission any export loss. Export packet loss becomes another form 
      of sampling, albeit a less desirable, and less controlled, form 
      of sampling. 
       
      On in formation as soon 
      as it includes one packet report. This could be achieved, for 
      example, by the contrary, retransmission following means: 
       
          -      the number of lost packet reports per export packets consumes 
      additional network resources. The requirement to store 
      unacknowledged data packet is an impediment not 
                  to exceed a maximum value, which can be configured to 
                  take the value 1. 
                   
          -      the ability to having ubiquitous support 
      for PSAMP. exclude report interpretation from any 
                  export packet that contains a packet report; 
       
      In order to jointly satisfy limit the timeliness and congestion 
      avoidance requirements delay in the transmission of Section 4.3, export 
      packets, a congestion aware 
      unreliable transport protocol configurable upper bound to the delay of an export 
      packet prior to transmission must be used. IPFIX provided. If the bound is compatible 
      with this requirement, since it mandates support of 
      exceeded the Stream 
      Control Transmission Protocol (SCTP) [SCTP] and export packet is dropped. This functionality can be 
      provided by the timed reliability service of the SCTP Partial 
      Reliability Extension [RFC-3758]. 
       
   8.3 Limiting Delay for Export Packets 
       
      The export exporting process may queue the report stream in order to 
      export multiple packet reports in a single export packet. Any 
      consequent delay must still allow for timely availability of 
      packet reports 
      at the collector as described in Section 6.5. just described. The timed reliability service 
      of the SCTP Partial Reliability Extension [RFC-3758] allows from 
    
   Duffield (Ed.)            Expires March 2005                [Page 20] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      the dropping of packets from the export buffer once their age in 
      the buffer exceeds a configurable bound. 
       
   8.4 Configurable Export Rate Limit 
       
      The export exporting process must have an export rate limit, 
      configurable per export exporting process. This is useful for two 
      reasons: 
       
           (i) Even without network congestion, the rate of packet 
           selection may exceed the capacity of the collector to 
           process reports, particularly when many export exporting processes 
           feed a common collector. Use of an export rate limit allows 
           control of the global input rate to the collector. 
       
           (ii) IPFIX provides for export using the User Datagram 
           Protocol (UDP) UDP as the transport 
           protocol in some circumstance, although 
    
   Duffield (Ed.)          Expires February 2005               [Page 21] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
    
    
           its use it deprecated. circumstances. An export rate limit allows 
           the capping of the export rate to match both path link 
           speeds and the capacity of the collector.  
    
   8.5 Collector Destination 
    
      When exporting to a remote collector, the collector is identified 
      by IP address, transport protocol, and transport port number. 
       
   8.6 Local Export 
       
      The report stream may be directly exported to on-board 
      measurement based applications, for example those that form 
      composite statistics from more than one packet. Local export may 
      be presented through an interface direct to the higher level 
      applications, i.e., through an API, rather than employing the 
      transport used for off-board export. Specification of such an API 
      is outside the scope of the PSAMP framework. 
       
      A possible example of local export could be that packets selected 
      by the PSAMP measurement process serve as the input for the IPFIX 
      protocol, which then forms flow records out of the stream of 
      selected packets.  
    
   9. Configuration and Management 
       
      A key requirement for PSAMP is the easy reconfiguration of the 
      parameters of the measurement process: those for selection, 
      packet reports and export. Examples are  
       
           (i) support of measurement-based applications that want to 
           drill-down on traffic detail in real-time;  
            
           (ii) collector-based rate reconfiguration. 
       

    
   Duffield (Ed.)            Expires March 2005                [Page 21] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      To facilitate reconfiguration and retrieval of parameters, they 
      are to reside in a Management Information Base (MIB). Mandatory 
      configuration, capabilities and monitoring objects will cover all 
      mandatory PSAMP functionality. 
       
      Secondary objects will cover the recommended and optional PSAMP 
      functionality, and must be provided when such functionality is 
      offered by a host. PSAMP device. Such PSAMP functionality includes 
      configuration of offered selectors, composite selectors, multiple 
      measurement processes, and report format including the choice of 
      fields to be reported. For further details concerning the PSAMP 
      MIB, see [PSAMP-MIB]. 
       
    
   Duffield (Ed.)          Expires February 2005               [Page 22] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
       
      PSAMP requires a uniform mechanism with which to access and 
      configure the MIB. SNMP access must be provided by the host of 
      the MIB. 
    
   10.       Feasibility and Complexity 
       
      In order for PSAMP to be supported across the entire spectrum of 
      networking equipment, it must be simple and inexpensive to 
      implement.  One can envision easy-to-implement instances of the 
      mechanisms described within this draft. Thus, for that subset of 
      instances, it should be straightforward for virtually all system 
      vendors to include them within their products. Indeed, sampling 
      and filtering operations are already realized in available 
      equipment. 
       
      Here we give some specific arguments to demonstrate feasibility 
      and comment on the complexity of hardware implementations. We 
      stress here that the point of these arguments is not to favor or 
      recommend any particular implementation, or to suggest a path for 
      standardization, but rather to demonstrate that the set of 
      possible implementations is not empty. 
       
   10.1     Feasibility 
          
   10.1.1  Filtering 
       
      Filtering consists of a small number of mask (bit-wise logical), 
      comparison and range (greater than) operations.  Implementation 
      of at least a small number of such operations is straightforward. 
      For example, filters for security access control lists (ACLs) are 
      widely implemented. This could be as simple as an exact match on 
      certain fields, or involve more complex comparisons and ranges. 
       
   10.1.2  Sampling 
       
      Sampling based on either counters (counter set, decrement, test 
      for equal to zero) or range matching on the hash of a packet 
      (greater than) is possible given a small number of selectors, 

    
   Duffield (Ed.)            Expires March 2005                [Page 22] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      although there may be some differences in ease of implementation 
      for hardware vs. software platforms. 
       
   10.1.3  Hashing  
          
      Hashing functions vary greatly in complexity.  Execution of a 
      small number of sufficient simple hash functions is implementable 
      at line rate. Concerning the input to the hash function, hop-
      invariant IP header fields (IP address, IP identification) and 
      TCP/UDP header fields (port numbers, TCP sequence number) drawn 
      from the first 40 bytes of the packet have been found to possess 
      a considerable variability; see [DuGr01]. 
       
    
   Duffield (Ed.)          Expires February 2005               [Page 23] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
       
   10.1.4  Reporting 
       
      The simplest packet report would duplicate the first n bytes of 
      the packet. However, such an uncompressed format may tax the 
      bandwidth available to the reporting process for high sampling 
      rates; reporting selected fields would save on this bandwidth. 
      Thus there is a trade-off between simplicity and bandwidth 
      limitations. 
       
   10.1.5  Export 
       
      Ease of exporting export packets depends on the system 
      architecture. Most systems should be able to support export by 
      insertion of export packets, even through the software path. 
        
   10.2    Potential Hardware Complexity 
       
      We now comment on the complexity of possible hardware 
      implementations. Achieving low constants for performance while 
      minimizing hardware resources is, of course, a challenge, 
      especially at very high clock frequencies. Most of these 
      operations, however, are very basic and their implementations 
      very well understood; in fact, the average ASIC designer simply 
      uses canned library instances of these operations rather than 
      design them from scratch. In addition, networking equipment 
      generally does not need to run at the fastest clock rates, 
      further reducing the effort required to get reasonably efficient 
      implementations. 
       
      Simple bit-wise logical operations are easy to implement in 
      hardware.  Such operations (NAND/NOR/XNOR/NOT) directly translate 
      to four-transistor gates.  Each bit of a multiple-bit logical 
      operation is completely independent and thus can be performed in 
      parallel incurring no additional performance cost above a single 
      bit operation. 
       
      Comparisons (EQ/NEQ) take O(lg(M)) stages of logic, where M is 
      the number of bits involved in the comparison.  The lg(M) is 
      required to accumulate the result into a single bit. 
    
   Duffield (Ed.)            Expires March 2005                [Page 23] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
       
      Greater than operations, as used to determine whether a hash 
      falls in a selection range, are a determination of the most 
      significant not-equivalent bit in the two operands.  The operand 
      with that most-significant-not-equal bit set to be one is greater 
      than the other.  Thus, a greater than operation is also an 
      O(lg(M)) stages of logic operation. Optimized implementations of 
      arithmetic operations are also O(lg(M)) due to propagation of the 
      carry bit. 
       
      Setting a counter is simply loading a register with a state. Such 
      an operation is simple and fast O(1).  Incrementing or 
      decrementing a counter is a read, followed by an arithmetic 
    
   Duffield (Ed.)          Expires February 2005               [Page 24] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 followed by an arithmetic 
      operation followed by a store.  Making the register dual-ported 
      does take additional space, but it is a well-understood 
      technique.  Thus, the increment/decrement is also an O(lg(M)) 
      operation. 
       
      Hashing functions come in a variety of forms.  The computation 
      involved in a standard Cyclic Redundancy Code (CRC) for example 
      are essentially a set of XOR operations, where the intermediate 
      result is stored and XORed with the next chunk of data.  There 
      are only O(1) operations and no log complexity operations.  Thus, 
      a simple hash function, such as CRC or generalizations thereof, 
      can be implemented in hardware very efficiently. 
       
      At the other end of the range of complexity, the MD5 function 
      uses a large number of bit-wise conditional operations and 
      arithmetic operations.  The former are O(1) operations and the 
      latter are O(lg(M)). MD5 specifies 256 32b ADD operations per 16B 
      of input processed.  Consider processing 10Gb/sec at 100MHz (this 
      processing rate appears to be currently available). This requires 
      processing 12.5B/cycle, and hence at least 200 adders, a sizeable 
      number. Because of data dependencies within the MD5 algorithm, 
      the adders cannot be simply run in parallel, thus requiring 
      either faster clock rates and/or more advanced architectures. 
      Thus, selection hashing functions as complex as MD5 may be 
      precluded for ubiquitous use at full line rate. This motivates 
      exploring the use of selection hash functions with complexity 
      somewhere between that of MD5 and CRC. However, identification 
      hashing with MD5 on only selected packets is feasible at a 
      sufficiently low sampling frequency. 
          
   11.       Applications  
          
      We first describe several representative operational applications 
      that require traffic measurements at various levels of temporal 
      and spatial granularity. Some of the goals here appear similar to 
      those of IPFIX, at least in the broad classes of applications 
      supported. The major benefit of PSAMP is the support of new 
      network management applications, specifically, those enabled by 
      the packet selectors that it supports.  
    
   Duffield (Ed.)            Expires March 2005                [Page 24] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
       
   11.1    Baseline Measurement and Drill Down 
       
      Packet sampling is ideally suited to determine the composition of 
      the traffic across a network. The approach is to enable 
      measurement on a cut-set of the network links such that each 
      packet entering the network is seen at least once, for example, 
      on all ingress links. Unfiltered sampling with a relatively low 
      frequency establishes baseline measurements of the network 
      traffic. Packet reports include packet attributes of common 
      interest: source and destination address and port numbers, 
      prefix, protocol number, type of service, etc. Traffic matrices 
      are indicated by reporting source and destination AS matrices. 
    
   Duffield (Ed.)          Expires February 2005               [Page 25] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
      Absolute traffic volumes are estimated by renormalizing the 
      sampled traffic volumes through division by either the target 
      sampling frequency, or by the attained sampling frequency (as 
      derived by interface packet counters included in the report 
      stream) 
       
      Suppose an operator or a measurement-based application detects an 
      interesting subset of a packet stream, as identified by a 
      particular packet attribute. Real-time drill-down to that subset 
      is achieved by instantiating a new measurement process on the 
      same packet stream from which the subset was reported. The 
      selection process of the new measurement process filters 
      according to the attribute of interest, and composes with 
      sampling if necessary to manage the frequency of packet 
      selection. 
       
   11.2    Trajectory Sampling 
       
      Trajectory sampling is the selection of a subset of packets at 
      either all of a set of observation points or none of them. 
      Trajectory sampling is realized by hash-based sampling if all 
      observation points in the set apply a common hash function to a 
      portion of the packet content that is invariant along the packet 
      path. (Thus, fields such at TTL and CRC are excluded).  
       
      The trajectory followed by a packet is reconstructed from PSAMP 
      reports on it that reach the collector. Reports on a given packet 
      are associated either by matching a label comprising the 
      invariant reported packet content, or possibly some digest of it. 
      The reconstruction of trajectories, and methods for dealing with 
      possible ambiguities due to label collisions (identical labels 
      reported by different packets) and potential loss of reports in 
      transmission are dealt with in [DuGr01], [DuGeGr02] and [DuGr04]. 
       
   11.3    Passive Performance Measurement 
         
      Trajectory sampling enables the tracking of the performance 
      experience by customer traffic, customers identified by a list of 
      source or destination prefixes, or by ingress or egress 
    
   Duffield (Ed.)            Expires March 2005                [Page 25] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      interfaces. Operational uses include the verification of Service 
      Level Agreements (SLAs), and troubleshooting following a customer 
      complaint. 
       
      In this application, trajectory sampling is enabled at all 
      network ingress and egress interfaces. Rates of loss in transit 
      between ingress and egress are estimated from the proportion of 
      trajectories for which no egress report is received. Note that 
      loss of customer packets is distinguishable from loss of packet 
      reports through use of report sequence numbers. Assuming 
      synchronization of clocks between different entities, delay of 
      customer traffic across the network may also be measured; see 
      [Zs02]. 
    
   Duffield (Ed.)          Expires February 2005               [Page 26] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
       
      Extending hash-selection to all interfaces in the network would 
      enable attribution of poor performance to individual network 
      links. 
       
   11.4    Troubleshooting 
       
      PSAMP reports can also be used to diagnose problems whose 
      occurrence is evident from aggregate statistics, per interface 
      utilization and packet loss statistics.  These statistics are 
      typically moving averages over relatively long time windows, 
      e.g., 5 minutes, and serve as a coarse-grain indication of 
      operational health of the network. The most common method of 
      obtaining such measurements are through the appropriate SNMP MIBs 
      (MIB-II [RFC-1213] and vendor-specific MIBs.) 
       
      Suppose an operator detects a link that is persistently 
      overloaded and experiences significant packet drop rates. There 
      is a wide range of potential causes: routing parameters (e.g., 
      OSPF link weights) that are poorly adapted to the traffic matrix, 
      e.g., because of a shift in that matrix; a denial of service 
      attack or a flash crowd; a routing problem (link flapping). In 
      most cases, aggregate link statistics are not sufficient to 
      distinguish between such causes, and to decide on an appropriate 
      corrective action. For example, if routing over two links is 
      unstable, and the links flap between being overloaded and 
      inactive, this might be averaged out in a 5 minute window, 
      indicating moderate loads on both links. 
       
      Baseline PSAMP measurement of the congested link, as described in 
      Section 11.1, enables measurements that are fine grained in both 
      space and time. The operator has to be able to determine how many 
      bytes/packets are generated for each source/destination address, 
      port number, and prefix, or other attributes, such as protocol 
      number, MPLS forwarding equivalence class (FEC), type of service, 
      etc. This allows the precise determination of the nature of the 
      offending traffic. For example, in the case of a Distributed 
      Denial of Service(DDoS) attack, the operator would see a 

    
   Duffield (Ed.)            Expires March 2005                [Page 26] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
      significant fraction of traffic with an identical destination 
      address. 
       
      In certain circumstances, precise information about the spatial 
      flow of traffic through the network domain is required to detect 
      and diagnose problems and verify correct network behavior. In the 
      case of the overloaded link, it would be very helpful to know the 
      precise set of paths that packets traversing this link follow. 
      This would readily reveal a routing problem such as a loop, or a 
      link with a misconfigured weight. More generally, complex 
      diagnosis scenarios can benefit from measurement of traffic 
      intensities (and other attributes) over a set of paths that is 
      constrained in some way. For example, if a multihomed customer 
      complains about performance problems on one of the access links 
    
   Duffield (Ed.)          Expires February 2005               [Page 27] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
      from a particular source address prefix, the operator should be 
      able to examine in detail the traffic from that source prefix 
      which also traverses the specified access link towards the 
      customer. 
       
      While it is in principle possible to obtain the spatial flow of 
      traffic through auxiliary network state information, e.g., by 
      downloading routing and forwarding tables from routers, this 
      information is often unreliable, outdated, voluminous, and 
      contingent on a network model. For operational purposes, a direct 
      observation of traffic flow provided by trajectory sampling is 
      more reliable, as it does not depend on any such auxiliary 
      information. For example, if there was a bug in a router's 
      software, direct observation would allow the diagnosis the effect 
      of this bug, while an indirect method would not.  
       
   12.       Security Considerations 
       
         Security considerations are addressed in: 
        
         - Section 4.1: item Robust Selection 
         - Section 4.3: item Secure Export   
         - Section 4.4: item Secure Configuration 
         
   13.       Normative References 
       
           [PSAMP-TECH] T. Zseby, M. Molina, F. Raspall , Raspall, N. G. Duffield, 
              Sampling and Filtering Techniques for IP Packet 
              Selection, RFC XXXX. [Currently Internet Draft, draft-
              ietf-psamp-sample-tech-04.txt, work in progress, February 
              2004. 
       
           [PSAMP-MIB] T. Dietz, B. Claise, Definitions of Managed 
              Objects for Packet Sampling, , RFC XXXX. [Currently 
              Internet Draft, draft-ietf-psamp-
              mib-03.txt, draft-ietf-psamp-mib-03.txt, work in 
              progress, July 2004.] 
            

    
   Duffield (Ed.)            Expires March 2005                [Page 27] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
           [PSAMP-PROTO] B. Claise (Ed.) Packet Sampling (PSAMP) 
              Protocol Specifications, RFC XXXX. [Currently Internet 
              Draft draft-ietf-psamp-protocol-01.txt, work in progress, 
              February 2004.] 
            
           [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, 
              Information Model for Packet Sampling Exports, RFC XXXX.  
              [Currently Internet Draft, draft-ietf-psamp-info-02, July  
              2004 
       
       
   14.       Informative References 
       
           [B88] R.T. Braden, A pseudo-machine for packet monitoring 
              and statistics, in Proc ACM SIGCOMM 1988 

    
   Duffield (Ed.)          Expires February 2005               [Page 28] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
       
           [IPFIX-INFO] Calato, P, Meyer, J, Quittek, J, "Information 
              Model for IP Flow Information Export" draft-ietf-ipfix-
              info-04, November 2003 
       
           [ClPB93] K.C. Claffy, G.C. Polyzos, H.-W. Braun, Application 
              of Sampling Methodologies to Network Traffic 
              Characterization, Proceedings of ACM SIGCOMM'93, San 
              Francisco, CA, USA, September 13-17, 1993 
        
           [IPFIX-PROTO]   B. Claise,  Mark Fullmer ,Paul  B. Stewart, G. Sadasivan, M. 
              Fullmer,P. Calato , 
              Reinaldo R. Penno, IPFIX Protocol 
              Specifications , Internet Draft, draft-ietf-ipfix-protocol-4.txt, July draft-ietf-ipfix-
              protocol-05.txt, August 2004. 
            
           [RFC-2460] S. Deering, R. Hinden, Internet Protocol, Version 
              6 (IPv6) Specification, RFC 2460, December 1998. 
            
           [DuGr01] N. G. Duffield and M. Grossglauser, Trajectory 
              Sampling for Direct Traffic Observation, IEEE/ACM Trans. 
              on Networking, 9(3), 280-292, June 2001. 
            
           [DuGeGr02] N.G. Duffield, A. Gerber, M. Grossglauser, 
              Trajectory Engine: A Backend for Trajectory Sampling, 
              IEEE Network Operations and Management Symposium 2002, 
              Florence, Italy, April 15-19, 2002. 
            
           [DuGr04] N. G. Duffield and M. Grossglauser, Trajectory 
              Sampling with Unreliable Reporting, Proc IEEE Infocom 
              2004, Hong Kong, March 2004, 
            
            
           [RFC-2914] S. Floyd, Congestion Control Principles, RFC 
              2914, September 2000. 
               
               

    
   Duffield (Ed.)            Expires March 2005                [Page 28] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
           [RFC-2804] IAB and IESG, Network Working Group, IETF Policy 
              on Wiretapping, RFC 2804, May 2000 
            
           [RFC-1213] - K. McCloghrie, M. Rose, Management Information 
              Base for Network Management of TCP/IP-based 
              internets:MIB-II, RFC 1213, March 1991. 
            
            
           [RFC-3176] P. Phaal, S. Panchen, N. McKee, InMon 
              Corporation's sFlow: A Method for Monitoring Traffic in 
              Switched and Routed Networks, RFC 3176, September 2001 
            
           [RFC-2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, 
              Framework for IP Performance Metrics, RFC 2330, May 1998 
            
           [RFC-791] J. Postel, "Internet Protocol", STD 5, RFC 791, 
              September 1981. 
            
           [UDP]  Postel, J., "User Datagram Protocol" RFC 768, August 
              1980 
    
           [IPFIX-REQUIRE] J. Quittek, T. Zseby, B. Claise, S. Zander, 
              Requirements for IP Flow Information Export, Internet 

    
   Duffield (Ed.)          Expires February 2005               [Page 29] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
              Draft draft-ietf-ipfix-reqs-16.txt, work in progress, 
              June 2004. 
            
           [RFC1771]   Rekhter, Y. and T. Li, "A Border Gateway 
              Protocol 4 (BGP-4)", RFC 1771, March 1995. 
                   
           [RFC-3031]  Rosen, E., Viswanathan, A. and R. Callon, 
              "Multiprotocol Label Switching Architecture", RFC 3031, 
              January 2001. 
            
           [SPSJTKS01] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. 
              E. Jones, F. Tchakountio, S. T. Kent, W. T. Strayer, 
              Hash-Based IP Traceback, Proc. ACM SIGCOMM 2001, San 
              Diego, CA, September 2001. 
            
           [RFC-2960] R. Stewart, (ed.) "Stream Control Transmission 
              Protocol", RFC 2960, October 2000. 
            
           [RFC-3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. 
              Conrad, "SCTP Partial Reliability Extension", RFC 3758, 
              May 2004. 
            
           [Zs02] T. Zseby, ``Deployment of Sampling Methods for SLA 
              Validation with Non-Intrusive Measurements'', Proceedings 
              of Passive and Active Measurement Workshop (PAM 2002), 
              Fort Collins, CO, USA, March 25-26, 2002  
       
   15.       Authors' Addresses 
       
    
   Duffield (Ed.)            Expires March 2005                [Page 29] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
         Derek Chiou 
         Avici Systems 
         101 Billerica Ave 
         North Billerica, MA 01862 
         Phone: +1 978-964-2017 
         Email: dchiou@avici.com 
       
         Benoit Claise 
         Cisco Systems 
         De Kleetlaan 6a b1 
         1831 Diegem 
         Belgium 
         Phone: +32 2 704 5622 
         Email: bclaise@cisco.com 
       
         Nick Duffield 
         AT&T Labs - Research 
         Room B-139 
         180 Park Ave 
         Florham Park NJ 07932, USA 
         Phone: +1 973-360-8726 
         Email: duffield@research.att.com 
       
         Albert Greenberg 
         AT&T Labs - Research 
         Room A-161 
    
   Duffield (Ed.)          Expires February 2005               [Page 30] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
         180 Park Ave 
         Florham Park NJ 07932, USA 
         Phone: +1 973-360-8730 
         Email: albert@research.att.com 
       
         Matthias Grossglauser 
         School of Computer and Communication Sciences 
         EPFL 
         1015 Lausanne 
         Switzerland 
         Email: matthias.grossglauser@epfl.ch 
       
         Peram Marimuthu 
         Cisco Systems 
         170, W. Tasman Drive 
         San Jose, CA 95134 
         Phone: (408) 527-6314 
         Email: peram@cisco.com 
       
         Jennifer Rexford 
         AT&T Labs - Research 
         Room A-169 
         180 Park Ave 
         Florham Park NJ 07932, USA 
         Phone: +1 973-360-8728 
         Email: jrex@research.att.com 
    
   Duffield (Ed.)            Expires March 2005                [Page 30] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
        
         Ganesh Sadasivan  
         Cisco Systems  
         170 W. Tasman Drive  
         San Jose, CA 95134  
         Phone: (408) 527-0251  
         Email: gsadasiv@cisco.com 
       
   16.       Intellectual Property Statements 
       
      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 
      RFC 3668. 
       
      The IETF has been notified by AT&T Corp. of intellectual property 
      rights claimed in regard to some or all of the specification 
      contained in this document. For more information, see  
      http://www.ietf.org/ietf/IPR/att-ipr-draft-ietf-psamp-
      framework.txt 
    
      The IETF has been notified by Cisco Corp. of intellectual 
      property rights claimed in regard to some or all of the 


    
   Duffield (Ed.)          Expires February 2005               [Page 31] 
    
   Internet Draft      Packet Selection and Reporting        August 2004 
      specification contained in this document. For more information, 
      see  
      http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-psamp-
      protocol.txt 
       
   17.       Full Copyright Statement 
       
      Copyright (C) The Internet Society (2004).  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 translations of it may be copied and furnished 
      to others, and derivative works that comment on or otherwise 
      explain it or assist in its implementation may be prepared, 
      copied, published and distributed, in whole or in part, without 
      restriction of any kind, provided that the above copyright notice 
      and this paragraph are included on all such copies and derivative 
      works. However, this document itself may not be modified in any 
      way, such as by removing the copyright notice or references to 
      the Internet Society or other Internet organizations, except as 
      needed for the purpose of developing Internet standards in which 
      case the procedures for copyrights defined in the Internet 
      Standards process must be followed, or as required to translate 
      it into languages other than English. 
       
      The limited permissions granted above are perpetual and will not 
      be revoked by the Internet Society or its successors or assigns. 
    
   Duffield (Ed.)            Expires March 2005                [Page 31] 
    
   Internet Draft      Packet Selection and Reporting     September 2004 
    
    
    
      This document and the information contained herein is provided on 
      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 
      ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 
      IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 
      OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 
      IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 
      PURPOSE. 
    











































    
   Duffield (Ed.)            Expires February March 2005                [Page 32] 
    



--------------020900030702040403060700--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


From owner-psamp@ops.ietf.org  Tue Aug 31 04:32:47 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28779
	for ; Tue, 31 Aug 2004 04:32:47 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1C23c9-000PIC-Gw
	for psamp-data@psg.com; Tue, 31 Aug 2004 08:03:37 +0000
Received: from [195.37.70.15] (helo=venus.office)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1C23by-000PFp-GQ
	for psamp@ops.ietf.org; Tue, 31 Aug 2004 08:03:26 +0000
Received: from netlab.nec.de (molina.office [10.1.1.126])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 527B5169337
	for ; Tue, 31 Aug 2004 10:03:25 +0200 (CEST)
Message-ID: <413430CC.8000803@netlab.nec.de>
Date: Tue, 31 Aug 2004 10:03:24 +0200
From: Maurizio Molina 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: psamp 
Subject: Re: Last-Call: comments on draft-ietf-psamp-framework-07.txt + draft-ietf-psamp-framework-08.txt
References: <4133AA8C.1000401@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
> 6. Section 5.2, under "Router State Filtering".
> We know that the filtering definition says:
>
>        Filtering: a filter is a selection operation that selects a 
>        packet deterministically based on the packet content, its 
>        treatment, and functions of these occurring in the selection 
>        state.
>
> We must add a note that the "Router State Filtering" only deals with 
> the packet treatment part of the definition.


Easier way out: put "or" in the definition. That is:

        Filtering: a filter is a selection operation that selects a 
        packet deterministically based on the packet content, or its 
        treatment, or functions of these occurring in the selection 
        state.

Maurizio



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


From owner-psamp@ops.ietf.org  Tue Aug 31 08:23:24 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12110
	for ; Tue, 31 Aug 2004 08:23:24 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1C27Yj-000Ayg-AX
	for psamp-data@psg.com; Tue, 31 Aug 2004 12:16:21 +0000
Received: from [144.254.15.118] (helo=strange-brew.cisco.com)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1C27YY-000Awc-HX
	for psamp@ops.ietf.org; Tue, 31 Aug 2004 12:16:10 +0000
Received: from [192.168.0.4] (ams-clip-vpn-dhcp4344.cisco.com [10.61.80.247])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i7VCG8g09894;
	Tue, 31 Aug 2004 14:16:08 +0200 (CEST)
Message-ID: <41346C08.4080208@cisco.com>
Date: Tue, 31 Aug 2004 14:16:08 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Maurizio Molina 
CC: psamp 
Subject: Re: Last-Call: comments on draft-ietf-psamp-framework-07.txt +	draft-ietf-psamp-framework-08.txt
References: <4133AA8C.1000401@cisco.com> <413430CC.8000803@netlab.nec.de>
In-Reply-To: <413430CC.8000803@netlab.nec.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=2.64
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Maurizio,

>>
>> 6. Section 5.2, under "Router State Filtering".
>> We know that the filtering definition says:
>>
>>        Filtering: a filter is a selection operation that selects a 
>>        packet deterministically based on the packet content, its 
>>        treatment, and functions of these occurring in the selection 
>>        state.
>>
>> We must add a note that the "Router State Filtering" only deals with 
>> the packet treatment part of the definition.
>
>
>
> Easier way out: put "or" in the definition. That is:
>
>        Filtering: a filter is a selection operation that selects a 
>        packet deterministically based on the packet content, or its 
>        treatment, or functions of these occurring in the selection 
>        state.

Nice improvement. That will do.
I still think that the little extra precision in the "Router State 
Filtering" section (expressing that it only deals with the packet 
treatment part of the definition) is worth adding.
Note that draft-ietf-psamp-sample-tech-04.txt must also be updated.

Regards, Benoit.

>
> Maurizio
>
>
>
> -- 
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


From owner-psamp@ops.ietf.org  Tue Aug 31 15:43:52 2004
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20906
	for ; Tue, 31 Aug 2004 15:43:51 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD))
	id 1C2ENu-000My3-QX
	for psamp-data@psg.com; Tue, 31 Aug 2004 19:33:38 +0000
Received: from [132.151.1.176] (helo=ietf.org)
	by psg.com with esmtp (Exim 4.41 (FreeBSD))
	id 1C2ENE-000Mun-1i
	for psamp@ops.ietf.org; Tue, 31 Aug 2004 19:32:56 +0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20076;
	Tue, 31 Aug 2004 15:31:28 -0400 (EDT)
Message-Id: <200408311931.PAA20076@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: psamp@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-psamp-framework-08.txt
Date: Tue, 31 Aug 2004 15:31:28 -0400
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Packet Sampling Working Group of the IETF.

	Title		: A Framework for Packet Selection and Reporting
	Author(s)	: N. Duffield
	Filename	: draft-ietf-psamp-framework-08.txt
	Pages		: 32
	Date		: 2004-8-31
	
This document specifies a framework for the PSAMP (Packet 
      Sampling) protocol. The functions of this protocol are to select 
      packets from a stream according to a set of standardized reports, 
      form a stream of reports on the selected packets, and to export 
      that stream to a collector. This framework details the components 
      of this architecture, then describes some generic requirements, 
      motivated the dual aims of ubiquitous deployment and utility of 
      the reports for applications. Detailed requirements for 
      selection, reporting and export are described, along with 
      configuration of the PSAMP functions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-08.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-psamp-framework-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-psamp-framework-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-8-31154111.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-psamp-framework-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-psamp-framework-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-8-31154111.I-D@ietf.org>

--OtherAccess--

--NextPart--



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: