From owner-issll@mercury.lcs.mit.edu Sun Sep 10 17:44:27 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10305 for ; Sun, 10 Sep 2000 17:44:27 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA01951 for issll-outgoing; Sun, 10 Sep 2000 16:43:32 -0400 (EDT) Received: from photon (photon.idirect.com [207.136.80.123]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA01949 for ; Sun, 10 Sep 2000 16:43:30 -0400 (EDT) From: westoakwireless@yahoo.com Received: from bc-van-reg-a53-01-89.look.ca ([216.66.142.89] helo=yahoo.com) by photon.idirect.com with smtp (Exim 3.12 #9) id 13Xu3H-0000lm-00; Sun, 10 Sep 2000 04:28:51 +0500 Reply-To: westoakwireless@yahoo.com To: westoakwireless@yahoo.com Subject: FREE Investor's kit - Wireless Company Goes Public Message-Id: Date: Sun, 10 Sep 2000 04:28:51 +0500 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk ************************************************** TELESIS NORTH GOES PUBLIC September 9, 2000 Telesis North, (stock symbol: WO.CDNX), is a wireless connectivity software company providing applications for the exploding wireless communications market. INVESTMENT HIGHLIGHTS: -The company has been in business since 1989, with an established customer base and worldwide distribution channels. -Founded by 2 former engineers from Nortel Networks, world leader in telecom technology and one of the most active stocks on the TSE. -Strong management team that includes a former Vice President of Infowave Software (IW. TSE), a wireless software stock in the same niche as Telesis North whose market capitalization hit 1.3 billion dollars! -Strong working relationships with Inmarsat, Microsoft, Telenor, SingTel, Eicon, and Fuji Trading. -Recently announce distribution agreement and investment from Stratos Global Corporation (SGB. TSE), one of Canada’s fastest growing companies and a world leader in satellite and wireless communications services. Telesis North is in the process of going public through a merger with West Oak Resource Corp. For a FREE company information kit click: For the latest NEWS on the Company Click Here: ************************************************************** This bulletin has been sent to you at no charge. THIS IS NOT A RECOMMENDATION TO BUY OR SELL ANY SECURITY! To remove yourself from this mailing list click here: From owner-issll@mercury.lcs.mit.edu Tue Sep 12 07:59:44 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00783 for ; Tue, 12 Sep 2000 07:59:44 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA00498 for issll-outgoing; Tue, 12 Sep 2000 06:58:25 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id GAA00593 for ; Tue, 12 Sep 2000 06:50:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28655; Tue, 12 Sep 2000 06:50:21 -0400 (EDT) Message-Id: <200009121050.GAA28655@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: issll@mercury.lcs.mit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt Date: Tue, 12 Sep 2000 06:50:20 -0400 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Services over Specific Link Layers Working Group of the IETF. Title : Capability Negotiation: The RSVP CAP Object Author(s) : S. Hamid Filename : draft-ietf-issll-rsvp-cap-00.txt Pages : 6 Date : 11-Sep-00 The DCLASS object is proposed in [DCLASS] to represent and carry Differentiated Services Code Points (DSCPs) within RSVP messages. The principle use of the DCLASS object is to carry DSCP information between a DS network and upstream nodes that may wish to mark packets with DSCP values. A network element in the DS network determines the value for DSCP which is further carried as a DCLASS object in RSVP RESV message to the sender host. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-00.txt 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-issll-rsvp-cap-00.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-issll-rsvp-cap-00.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: <20000911143408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-issll-rsvp-cap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-issll-rsvp-cap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000911143408.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-issll@mercury.lcs.mit.edu Tue Sep 12 11:14:12 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06180 for ; Tue, 12 Sep 2000 11:14:12 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA01233 for issll-outgoing; Tue, 12 Sep 2000 10:01:53 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca ([216.241.231.251]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA01223 for ; Tue, 12 Sep 2000 10:01:51 -0400 (EDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Sep 2000 07:05:12 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E48@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt Date: Tue, 12 Sep 2000 07:05:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Hi, To the author of this draft: Nice draft, but I think you have completely mixed up the meanings of upstream and downstream in your draft. In general the PATH message travels from upstream to downstream and the RESV message travels from downstream to upstream. In this draft sometimes this is true but in most cases it is completely reversed. The way the draft is currently written is not readable. Regards, -Shahram -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, September 12, 2000 6:50 AM Cc: issll@mercury.lcs.mit.edu Subject: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Services over Specific Link Layers Working Group of the IETF. Title : Capability Negotiation: The RSVP CAP Object Author(s) : S. Hamid Filename : draft-ietf-issll-rsvp-cap-00.txt Pages : 6 Date : 11-Sep-00 The DCLASS object is proposed in [DCLASS] to represent and carry Differentiated Services Code Points (DSCPs) within RSVP messages. The principle use of the DCLASS object is to carry DSCP information between a DS network and upstream nodes that may wish to mark packets with DSCP values. A network element in the DS network determines the value for DSCP which is further carried as a DCLASS object in RSVP RESV message to the sender host. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-00.txt 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-issll-rsvp-cap-00.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-issll-rsvp-cap-00.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. From owner-issll@mercury.lcs.mit.edu Tue Sep 12 17:41:45 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14527 for ; Tue, 12 Sep 2000 17:41:42 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA04168 for issll-outgoing; Tue, 12 Sep 2000 16:34:24 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA03917 for ; Tue, 12 Sep 2000 16:34:22 -0400 (EDT) Message-Id: <200009122034.QAA03917@mercury.lcs.mit.edu> Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Tue, 12 Sep 2000 09:37:25 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id SQ9VB5KG; Tue, 12 Sep 2000 07:33:52 -0700 Received: from tweedy (dhcp223-145.engeast.baynetworks.com [192.32.223.145]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id SHHJ198X; Tue, 12 Sep 2000 10:33:51 -0400 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 12 Sep 2000 10:28:27 -0400 To: Shahram Davari X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt Cc: issll@mercury.lcs.mit.edu In-Reply-To: <64DC8FA90382D411BA060090277AEE41774E48@nt-exchange-bby.pmc -sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk May be some clarification of flow direction as follows is needed? Sender and Receiver are with respect to the uni-directional packet flow. Downstream = Sender towards Receiver. Upstream = Receiver towards Sender. Path Msg travels from Senders towards Receivers, ResV Msg travels from Receivers towards Senders. Maybe the use of "toward Receivers" and "toward Senders" is more concise? -- Kwok -- At 07:05 AM 9/12/00 -0700, Shahram Davari wrote: >Hi, > >To the author of this draft: > >Nice draft, but I think you have completely mixed up the meanings of >upstream and downstream in your draft. In general the PATH message travels >from upstream to downstream and the RESV message travels from downstream to >upstream. In this draft sometimes this is true but in most cases it is >completely reversed. The way the draft is currently written is not readable. > > >Regards, >-Shahram > > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Tuesday, September 12, 2000 6:50 AM >Cc: issll@mercury.lcs.mit.edu >Subject: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Integrated Services over Specific Link >Layers Working Group of the IETF. > > Title : Capability Negotiation: The RSVP CAP Object > Author(s) : S. Hamid > Filename : draft-ietf-issll-rsvp-cap-00.txt > Pages : 6 > Date : 11-Sep-00 > >The DCLASS object is proposed in [DCLASS] to represent and carry >Differentiated Services Code Points (DSCPs) within RSVP messages. The >principle use of the DCLASS object is to carry DSCP information >between a DS network and upstream nodes that may wish to mark packets >with DSCP values. A network element in the DS network determines the >value for DSCP which is further carried as a DCLASS object in RSVP >RESV message to the sender host. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-00.txt > >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-issll-rsvp-cap-00.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-issll-rsvp-cap-00.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. > From owner-issll@mercury.lcs.mit.edu Tue Sep 12 17:45:53 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14583 for ; Tue, 12 Sep 2000 17:45:50 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA04269 for issll-outgoing; Tue, 12 Sep 2000 16:45:40 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca ([216.241.231.251]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA04260 for ; Tue, 12 Sep 2000 16:45:38 -0400 (EDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Sep 2000 13:48:59 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E4B@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kwok-Ho Chan'" , Shahram Davari Cc: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt Date: Tue, 12 Sep 2000 13:48:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk There are two separate issues: 1) The draft is inconsistent in it uses of upstream and downstream words. In some parts of the draft upstream mean sender towards receiver, yet in some other part of the draft it means receiver toward sender. 2) Usually upstream means from sender of data to receiver of data (note it is data not control) and downstream means from receiver of data to sender of data. The first issue is unacceptable, while the second issue is a definition only, and a different definition may be used if stated clearly. Regards, -Shahram -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Tuesday, September 12, 2000 10:28 AM To: Shahram Davari Cc: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt May be some clarification of flow direction as follows is needed? Sender and Receiver are with respect to the uni-directional packet flow. Downstream = Sender towards Receiver. Upstream = Receiver towards Sender. Path Msg travels from Senders towards Receivers, ResV Msg travels from Receivers towards Senders. Maybe the use of "toward Receivers" and "toward Senders" is more concise? -- Kwok -- At 07:05 AM 9/12/00 -0700, Shahram Davari wrote: >Hi, > >To the author of this draft: > >Nice draft, but I think you have completely mixed up the meanings of >upstream and downstream in your draft. In general the PATH message travels >from upstream to downstream and the RESV message travels from downstream to >upstream. In this draft sometimes this is true but in most cases it is >completely reversed. The way the draft is currently written is not readable. > > >Regards, >-Shahram > > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Tuesday, September 12, 2000 6:50 AM >Cc: issll@mercury.lcs.mit.edu >Subject: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Integrated Services over Specific Link >Layers Working Group of the IETF. > > Title : Capability Negotiation: The RSVP CAP Object > Author(s) : S. Hamid > Filename : draft-ietf-issll-rsvp-cap-00.txt > Pages : 6 > Date : 11-Sep-00 > >The DCLASS object is proposed in [DCLASS] to represent and carry >Differentiated Services Code Points (DSCPs) within RSVP messages. The >principle use of the DCLASS object is to carry DSCP information >between a DS network and upstream nodes that may wish to mark packets >with DSCP values. A network element in the DS network determines the >value for DSCP which is further carried as a DCLASS object in RSVP >RESV message to the sender host. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-00.txt > >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-issll-rsvp-cap-00.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-issll-rsvp-cap-00.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. > From owner-issll@mercury.lcs.mit.edu Tue Sep 12 18:21:04 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14757 for ; Tue, 12 Sep 2000 18:21:03 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA04590 for issll-outgoing; Tue, 12 Sep 2000 17:20:25 -0400 (EDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA04574 for ; Tue, 12 Sep 2000 17:20:18 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Tue, 12 Sep 2000 16:11:09 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 12 Sep 2000 16:14:52 -0500 Message-ID: From: "Muhammad Jaseemuddin" To: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt Date: Tue, 12 Sep 2000 16:14:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01CFE.7C757FC0" X-Orig: Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C01CFE.7C757FC0 Content-Type: text/plain Hi: I think the idea presented in the draft is a valid and logical response to the issue of when to return DCLASS object to a PHOP node. I am not sure whether a whole "new" object needs to be defined to carry the "marking capability" information about the previous node. I suggest the following alternative implementation. There is a flag byte in the session object. Only one bit of that byte is defined as E_Police bit to determine the effective edge for policing. If the host is capable of policing that session, it resets the bit. Otherwise, it sets the bit and let the routers on the path determines which router can police, and the first router that can police resets the bit. We can view this byte as a capability byte. We can argue to define one more bit E_Mark bit to carry the marking capability information.. SESSION OBJECT flags 0x01 E_Police 0x02 E_Mark A node sets this bit in the PATH message if it is capable of marking the flow and requires a DCLASS object in the RESV message. The next hop RSVP node if finds the bit set, sends the DCLASS object to the previous hop node in the corresponding RESV message. A node resets this bit in the PATH message if it does not need the next hop node to return the DCLASS object. This implementation not only saves from defining an object, but also consistent with the E_Police bit. Similar to policing, the capablity to mark a flow is more meaningful on per session basis. Cheers, - Muhammad Jaseemuddin Nortelnetworks ------_=_NextPart_001_01C01CFE.7C757FC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt

Hi:

 I think the idea presented in = the draft is a valid and logical response to the issue of when to = return DCLASS object to a

PHOP node. I am not sure whether a = whole "new" object needs to be defined to carry the = "marking capability" information
about the previous node. I suggest = the following alternative implementation.

 There is a flag byte in the = session object. Only one bit of that byte is defined as E_Police bit to = determine the effective edge

for policing. If the host is capable = of policing that session, it resets the bit. Otherwise, it sets the bit = and let the routers on

the path determines which router can = police, and the first router that can police resets the bit.

 We can view this byte as a = capability byte. We can argue to define one more bit E_Mark bit to = carry the marking capability

information..

SESSION OBJECT

        flags
        =         0x01 E_Police
        =         0x02 E_Mark     A node sets this bit in = the PATH message if it is capable of marking the flow and requires =

         &nb= sp;           &nb= sp;           &nb= sp;  a DCLASS object in the RESV message. The next hop RSVP node = if finds the bit set, sends

         &nb= sp;           &nb= sp;           &nb= sp;  the DCLASS object to the previous hop node in the = corresponding RESV message. A node

         &nb= sp;           &nb= sp;           &nb= sp;  resets this bit in the PATH message if it does not need the = next hop node to return the

         &nb= sp;           &nb= sp;           &nb= sp;  DCLASS object.

 This implementation not only = saves from defining an object, but also consistent with the E_Police = bit. Similar to
policing, the capablity to mark a = flow is more meaningful on per session basis.

Cheers,
- Muhammad Jaseemuddin
  Nortelnetworks

------_=_NextPart_001_01C01CFE.7C757FC0-- From owner-issll@mercury.lcs.mit.edu Tue Sep 12 19:26:21 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15161 for ; Tue, 12 Sep 2000 19:26:21 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id SAA05246 for issll-outgoing; Tue, 12 Sep 2000 18:32:07 -0400 (EDT) Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id SAA05265; Tue, 12 Sep 2000 18:31:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu Message-Id: In-Reply-To: <64DC8FA90382D411BA060090277AEE41774E4B@nt-exchange-bby.pmc-sierra.bc.ca> References: <64DC8FA90382D411BA060090277AEE41774E4B@nt-exchange-bby.pmc-sierra.bc.ca> Date: Tue, 12 Sep 2000 18:31:38 -0400 To: Shahram Davari From: John Wroclawski Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt Cc: issll@mercury.lcs.mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk At 1:48 PM -0700 9/12/00, Shahram Davari wrote: >2) Usually upstream means from sender of data to receiver of data (note it >is data not control) and downstream means from receiver of data to sender >of data. Hi Shahram, I would have said the opposite (i.e, data flows downstream). Did you mistype, or is there an issue? John From owner-issll@mercury.lcs.mit.edu Wed Sep 13 10:25:13 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09126 for ; Wed, 13 Sep 2000 10:25:13 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA01085 for issll-outgoing; Wed, 13 Sep 2000 09:05:44 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca ([216.241.231.251]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id JAA01080 for ; Wed, 13 Sep 2000 09:05:42 -0400 (EDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 06:08:58 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E4E@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'John Wroclawski'" , Shahram Davari Cc: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt Date: Wed, 13 Sep 2000 06:09:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Sorry it was a mistype. You are correct. -Shahram -----Original Message----- From: John Wroclawski [mailto:jtw@lcs.mit.edu] Sent: Tuesday, September 12, 2000 6:32 PM To: Shahram Davari Cc: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt At 1:48 PM -0700 9/12/00, Shahram Davari wrote: >2) Usually upstream means from sender of data to receiver of data (note it >is data not control) and downstream means from receiver of data to sender >of data. Hi Shahram, I would have said the opposite (i.e, data flows downstream). Did you mistype, or is there an issue? John From owner-issll@mercury.lcs.mit.edu Wed Sep 20 08:15:05 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19955 for ; Wed, 20 Sep 2000 08:15:04 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA00631 for issll-outgoing; Wed, 20 Sep 2000 06:38:41 -0400 (EDT) Received: from bdcsql1.al-rostamani.co.ae ([194.170.227.9]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id GAA00626 for ; Wed, 20 Sep 2000 06:37:12 -0400 (EDT) Date: Wed, 20 Sep 2000 06:37:12 -0400 (EDT) From: nile333@kadet.co.uk Message-Id: <200009201037.GAA00626@mercury.lcs.mit.edu> Received: from SMTP agent by mail gateway Wed, 20 Sep 2000 14:40:05 --400 Received: from firewall-in.al-rostamani.co.ae by bdcsql1.al-rostamani.co.ae with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id TFDHQT1C; Wed, 20 Sep 2000 14:12:30 +0400 Received: from SMTP agent by mail gateway Wed, 20 Sep 2000 14:17:30 --400 To: nile333@kadet.co.uk Subject: So, How in the heck have you been? Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk So, How in the heck have you been? Do you remember holding previous conversations regarding business and money making opportunities? I did not send this to you in error! You Said: If only I could find an easier way to make a higher income! and If I had more money, I could spend more time with my Family, and less time at work and I sure could use more money so I could pay off my bills once and for all! And I would love to get involved in a business in which will generate money while I am not at work (like a Gas Pump)! Dear Friend, There is a possibility that we haven’t met, but you were chosen by someone to receive this E-Mail. Please, please, print this off and read thoroughly. Be sure that you don’t miss any of the points outlined. Then put it down, and then read it again. I am sending you a whole lot of information in which you might not understand the first time you read it. If you don’t believe this program will work for you, send it to 10-20 of your closest friends (in which you trust deeply), and ask them what they think? This really works! Have faith, don’t miss this opportunity, get involved also, and it will work for you as it does for us!!!! Due to the popularity of this letter on the Internet, A Major Nightly News Program recently dedicated an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make extra money at home. The results have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting. You will understand only if you get involved! ********** THE ENTIRE PLAN IS HERE BELOW ********** **** Print This Now For Future Reference **** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make AT LEAST $50,000 in less than 90 days! If not, forward this to someone who would like to make this kind of money. It works (like designed) but only for those who follow it to the letter! Please read this program THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! Hello, My name is Johnathon Rourke, I’m from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. Two years ago, the corporation I worked for the past twelve yearsdown-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year,I incurred many unforeseen financial problems. I owed my family, friends and creditors over$35,000. The economy was taking a toll on my business and I just could not seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life. I am writing to share the experience I hopes that this could change your life FOREVER. FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion,were not cost effective. They were either toodifficult for me to comprehend or the initial investment was too muchfor me to risk to see if they would work. But as I was saying, in December of 1997 I received this program.I didn’t send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly. I couldn’t believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. Like most of you I was still a little skeptical and a little worried about the legalaspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal ! After determining the program was LEGAL I decided WHY NOT!?!?? Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don’t need any paper for printing to send out the program, and because I also send the product (reports) by e-mail, my only expense is my time. In less than one week,I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON’T SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT SEND OUT MORE PROGRAMS UNTIL YOU! DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL. Well, I had 196 orders for REPORT #2. 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, received $58,000 with more coming in every day. I paid off ALL my debts and bought a much need new car! Please take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! Remember, it won’t work if you don’t try it. This program does work, But you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won’t work and you’ll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose toparticipate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are financial trouble like I was, or you want to start your own business, consider this a sign. I DID! $$ Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, cpuld not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn’t working. Finally, I figured it out. It wasn’t me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don’t have to tell you what happened to the unemployment rate because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, THE RICH GET RICHER ANDTHE POOR GET POORER. The traditional methods of making money will never allow you to move up or get rich, inflation will see to that You have just received the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few months than you have everimagined.I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copyof this exciting report to everyone you can think of. One of the people you send this to may send out 50,000 and your name will be on everyone of them! REMEMBER though, ------ the MORE YOU SEND OUT, the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU!! NOW DO IT!! BEFORE YOU delete this program from your in box, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. $$$ IT WORKS!!! $$$ Jody Jacobs Richmond, VA. HERE’S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS$$$$!!!! This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say BULL, please read this program carefully. This is not a chain letter,but a perfectly legal money making business. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we sell and deliver a product for EVERY dollar received. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the EASIEST marketing plan anywhere! It is simply order filling by e-mail! The product is informational and instructional material, keys to the secrets for everyone on how to open the doors to the magic world of E-COMMERCE, the information highway, the wave of the future ! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 each) They come to you by e-mail. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk e-mail service companies (search for bulk email) and have them send 25,000 50,000 emails for you about $49+. (4) Orders will come to you by postal mail simply e-mail them the Report they ordered. Let me ask you isn’t this about as easy as it gets? By the way there are over 50 MILLION e-mail address with millions more joining the internet each year so don’t worry about running out or saturation. People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and order one. Same thing with this letter. I received this letter many times then one day I decided it was time to try it. YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can’t sell them if you don’t order them). For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report.MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail each of the four reports.Save them on your computer so you can send them to the 1,000’s of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After you’ve ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire e-mail to send by e-mail to prospects. Report #1 will tell you how to download bulk email software and email address so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month! Your cost to participate in this is practically nothing ( surely you can afford $20 and initial bulk mailing cost). You obviously already have a computer and an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL let’s say that you decide to start small, just to see how it goes, and we’ll assume you and all those involved email out only 2,000 programs each. Let’s also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out thousands of thousands of programs instead of 2,000 (Why stop at 2000?) But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2.Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That’s 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! METHOD #2 PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let’s say you decide to start small to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response). Also assume that everyone else in YOUR ORGANIZATION gets only 10 downline members. Look how this small number accumulates to achieve the STAGGERING results below: 1St level your first 10 send you $5........................$50 2nd level 10 members from those 10 ($5 x 100)............$500 3rd level 10 members from those 100 ($5 x 1,000)......$5,000 4th level 10 members from those 1,000 ($5 x 10,000)..$50,000 $$$$$$ THIS TOTALS ------------------------------------------------55,5550 $$$$$ AMAZING ISN’T IT Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100’s of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! People are going to get emails about this plan from you or somebody else and many will work this plan the question is Don’t you want your name to be on the emails they will send out? *** DON’T MISS OUT !!!*** ***JUST TRY IT ONCE !!!*** ***SEE WHAT HAPPENS !!!*** ***YOU'LL BE AMAZED !!!*** ALWAYS PROVIDE SAME DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can’t advertise until they receive the report! GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:-- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets write: (a) the number & name of the report you are ordering (b) your e-mail address, and (c) your name & postal address. REPORT #1b The Insider’s Guide to Advertising for Free on the Internet ORDER REPORT #1 FROM: NICK NICHOLAS 473 MICHIGAN ST ST.PAUL, MN 55102 NOTE: I and every member below are dedicated at helping you with this program so it will work for you also. TRY US! REPORT #2 The Insider’s Guide to Sending Bulk E-Mail on the Internet ORDER REPORT #2 FROM: DIANE COLON 1811 TAMARIND AVE # 206 LOS ANGELES, CA. 90028 REPORT #3 The Secrets to Multilevel Marketing on the Internet ORDER REPORT #3 FROM: MELISSA HOGENMILLER 3709 MONHEIM ROAD CONOVER, WI 54519 REPORT #4 How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet ORDER REPORT #4 FROM: CATHY BARROW 10 SYCAMORE STREET CONWAY, SC 29527 *************TIPS FOR SUCCESS*************** TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letter (with your name on them). --ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be patient and persistent with this program- If you follow the instructions exactly results WILL FOLLOW. $$$$ ************ YOUR SUCCESS GUIDELINES *************** Follow these guidelines to guarantee your success: If you don’t receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mail until you do. Then a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don’t continue advertising or sending e-mail until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question: ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? 1. If the answer is no, then please look at the following facts about this super simple MLM program: NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start! Nothing to learn, No skills needed! (Surely you know how to send email?) 2. No equipment to buy you already have a computer and internet connection so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Email copies of the reports are FREE!) 4. All of your customers pay you in CASH! This program will change your LIFE FOREEVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above __ SUCCESS will be your reward. Thank you for your time and consideration. PLEASE NOT: If you need help with starting a business, registering a business name, learning now income tax is handled, etc., contact your local office of the Small Business Administration (A Federal Agency) 1-800-827-5722 for free help and answers to questions. Also the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington DC. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. From owner-issll@mercury.lcs.mit.edu Thu Sep 21 00:08:43 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16647 for ; Thu, 21 Sep 2000 00:08:42 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id XAA05034 for issll-outgoing; Wed, 20 Sep 2000 23:05:44 -0400 (EDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id XAA05018 for ; Wed, 20 Sep 2000 23:05:40 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Wed, 20 Sep 2000 14:37:25 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 20 Sep 2000 14:41:12 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E8035B691A@zwdld001.ca.nortel.com> From: "Hamid Syed" To: "'Shahram Davari'" , "Kwok-Ho Chan" , Shahram Davari Cc: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt Date: Wed, 20 Sep 2000 14:41:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0233A.B95848E0" X-Orig: Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0233A.B95848E0 Content-Type: text/plain; charset="iso-8859-1" Thanx Shahram for your comments. Sorry for a late response. I was away for a conference and did not have access to e-mails. First of all, my definition of upstream/downstream data flow could be different from what the actual definition is (asyou pointed out) but in terms of draft, i dont think there is inconsistency in the definition usage at different places. I would appreciate if you can point me to the actual locations where inconsistency is felt. regards Hamid Syed > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Tuesday, September 12, 2000 4:49 PM > To: Chan, Kwok-Ho [BL60:470:EXCH]; Shahram Davari > Cc: issll@mercury.lcs.mit.edu > Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt > > There are two separate issues: > > 1) The draft is inconsistent in it uses of upstream and downstream words. > In > some parts of the draft upstream mean sender towards receiver, yet in some > other part of the draft it means receiver toward sender. > > 2) Usually upstream means from sender of data to receiver of data (note it > is data not control) and downstream means from receiver of data to sender > of data. > > The first issue is unacceptable, while the second issue is a definition > only, and a different definition may be used if stated clearly. > > Regards, > -Shahram > > > > -----Original Message----- > From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] > Sent: Tuesday, September 12, 2000 10:28 AM > To: Shahram Davari > Cc: issll@mercury.lcs.mit.edu > Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt > > > May be some clarification of flow direction as follows is needed? > Sender and Receiver are with respect to the uni-directional packet flow. > Downstream = Sender towards Receiver. > Upstream = Receiver towards Sender. > > Path Msg travels from Senders towards Receivers, > ResV Msg travels from Receivers towards Senders. > > Maybe the use of "toward Receivers" and "toward Senders" is > more concise? > > -- Kwok -- > > > At 07:05 AM 9/12/00 -0700, Shahram Davari wrote: > >Hi, > > > >To the author of this draft: > > > >Nice draft, but I think you have completely mixed up the meanings of > >upstream and downstream in your draft. In general the PATH message > travels > >from upstream to downstream and the RESV message travels from downstream > to > >upstream. In this draft sometimes this is true but in most cases it is > >completely reversed. The way the draft is currently written is not > readable. > > > > > >Regards, > >-Shahram > > > > > >-----Original Message----- > >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >Sent: Tuesday, September 12, 2000 6:50 AM > >Cc: issll@mercury.lcs.mit.edu > >Subject: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > >This draft is a work item of the Integrated Services over Specific Link > >Layers Working Group of the IETF. > > > > Title : Capability Negotiation: The RSVP CAP Object > > Author(s) : S. Hamid > > Filename : draft-ietf-issll-rsvp-cap-00.txt > > Pages : 6 > > Date : 11-Sep-00 > > > >The DCLASS object is proposed in [DCLASS] to represent and carry > >Differentiated Services Code Points (DSCPs) within RSVP messages. The > >principle use of the DCLASS object is to carry DSCP information > >between a DS network and upstream nodes that may wish to mark packets > >with DSCP values. A network element in the DS network determines the > >value for DSCP which is further carried as a DCLASS object in RSVP > >RESV message to the sender host. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-00.txt > > > >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-issll-rsvp-cap-00.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-issll-rsvp-cap-00.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_001_01C0233A.B95848E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt

Thanx Shahram for = your comments. Sorry for a late response. I was away for a conference = and did not have access to e-mails.

 First of all, = my definition of upstream/downstream data flow could be different from = what the actual definition is (asyou pointed out) but in terms of = draft, i dont think there is inconsistency in the definition usage at = different places. I would appreciate if you can point me to the actual = locations where inconsistency is felt.

regards

Hamid Syed


    -----Original Message-----
    From:   Shahram Davari = [SMTP:Shahram_Davari@pmc-sierra.com]
    Sent:   Tuesday, September 12, 2000 4:49 PM
    To:     Chan, Kwok-Ho [BL60:470:EXCH]; Shahram Davari
    Cc:     issll@mercury.lcs.mit.edu
    Subject:       = RE: I-D = ACTION:draft-ietf-issll-rsvp-cap-00.txt

    There are two separate issues:

    1) The draft is inconsistent in it = uses of upstream and downstream words. In
    some parts of the draft upstream mean = sender towards receiver, yet in some
    other part of the draft it means = receiver toward sender.

    2) Usually upstream means from sender = of data to receiver of data (note it
    is data not control)  and = downstream means from receiver of data to sender
    of data.

    The first issue is unacceptable, while = the second issue is a definition
    only, and a different definition may = be used if stated clearly.

    Regards,
    -Shahram



    -----Original Message-----
    From: Kwok-Ho Chan = [mailto:khchan@nortelnetworks.c= om]
    Sent: Tuesday, September 12, 2000 = 10:28 AM
    To: Shahram Davari
    Cc: issll@mercury.lcs.mit.edu
    Subject: RE: I-D = ACTION:draft-ietf-issll-rsvp-cap-00.txt


    May be some clarification of flow = direction as follows is needed?
    Sender and Receiver are with respect = to the uni-directional packet flow.
    Downstream =3D Sender towards = Receiver.
    Upstream =3D Receiver towards = Sender.

    Path Msg travels from Senders towards = Receivers,
    ResV Msg travels from Receivers = towards Senders.

    Maybe the use of "toward Receivers= " and "toward Senders" is
    more concise?

    -- Kwok --

     
    At 07:05 AM 9/12/00 -0700, Shahram = Davari wrote:
    >Hi,
    >
    >To the author of this = draft:
    >
    >Nice draft, but I think you have = completely mixed up the meanings of
    >upstream and downstream in your = draft. In general the PATH message travels
    >from upstream to downstream and = the RESV message travels from downstream to
    >upstream. In this draft sometimes = this is true but in most cases it is
    >completely reversed. The way the = draft is currently written is not
    readable.
    >
    >
    >Regards,
    >-Shahram
    >
    >
    >-----Original Message-----
    >From: Internet-Drafts@ietf.org = [mailto:Internet-Drafts@ietf.org= ]
    >Sent: Tuesday, September 12, 2000 = 6:50 AM
    >Cc: = issll@mercury.lcs.mit.edu
    >Subject: I-D = ACTION:draft-ietf-issll-rsvp-cap-00.txt
    >
    >
    >A New Internet-Draft is available = from the on-line Internet-Drafts
    >directories.
    >This draft is a work item of the = Integrated Services over Specific Link
    >Layers Working Group of the = IETF.
    >
    >       = Title           : = Capability Negotiation: The RSVP CAP Object
    >       = Author(s)       : S. Hamid
    >       = Filename        : = draft-ietf-issll-rsvp-cap-00.txt
    >       = Pages           : 6
    >       = Date            : = 11-Sep-00
    >      
    >The DCLASS object is proposed in = [DCLASS] to represent and carry
    >Differentiated Services Code = Points (DSCPs) within RSVP messages. The
    >principle use of the DCLASS = object is to carry DSCP information
    >between a DS network and upstream = nodes that may wish to mark packets
    >with DSCP values. A network = element in the DS network determines the
    >value for DSCP which is further = carried as a DCLASS object in RSVP
    >RESV message to the sender = host.
    >
    >A URL for this Internet-Draft = is:
    >http://www.ietf.org/internet-drafts/draft-ietf-issll-r= svp-cap-00.txt
    >
    >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-issll-rsvp-cap-00.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-issll-rsvp-cap-00.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_001_01C0233A.B95848E0-- From owner-issll@mercury.lcs.mit.edu Thu Sep 21 11:55:01 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08565 for ; Thu, 21 Sep 2000 11:54:56 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA01219 for issll-outgoing; Thu, 21 Sep 2000 10:38:00 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca ([216.241.231.251]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA01214 for ; Thu, 21 Sep 2000 10:37:57 -0400 (EDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Sep 2000 07:41:27 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E63@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Hamid Syed'" , Shahram Davari , Kwok-Ho Chan , Shahram Davari Cc: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt Date: Thu, 21 Sep 2000 07:41:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C023DA.05908958" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C023DA.05908958 Content-Type: text/plain; charset="iso-8859-1" Hi, Here is an example from the abstract: 1) The principle use of the DCLASS object is to carry DSCP information between a DS network and upstream nodes that may wish to mark packets with DSCP values. 2) There may be situations where the sender host is not capable or may not wish to mark the packets. Currently, there is no way for the host or network devices to specify their capabilities to the upstream nodes. The first paragraph implies that the host is upstream of the DS network, while the second paragraph implies that the DS network is upstream of the node. Regards, -Shahram -----Original Message----- From: Hamid Syed [mailto:hmsyed@nortelnetworks.com] Sent: Wednesday, September 20, 2000 3:41 PM To: 'Shahram Davari'; Kwok-Ho Chan; Shahram Davari Cc: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt Thanx Shahram for your comments. Sorry for a late response. I was away for a conference and did not have access to e-mails. First of all, my definition of upstream/downstream data flow could be different from what the actual definition is (asyou pointed out) but in terms of draft, i dont think there is inconsistency in the definition usage at different places. I would appreciate if you can point me to the actual locations where inconsistency is felt. regards Hamid Syed -----Original Message----- From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] Sent: Tuesday, September 12, 2000 4:49 PM To: Chan, Kwok-Ho [BL60:470:EXCH]; Shahram Davari Cc: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt There are two separate issues: 1) The draft is inconsistent in it uses of upstream and downstream words. In some parts of the draft upstream mean sender towards receiver, yet in some other part of the draft it means receiver toward sender. 2) Usually upstream means from sender of data to receiver of data (note it is data not control) and downstream means from receiver of data to sender of data. The first issue is unacceptable, while the second issue is a definition only, and a different definition may be used if stated clearly. Regards, -Shahram -----Original Message----- From: Kwok-Ho Chan [ mailto:khchan@nortelnetworks.com ] Sent: Tuesday, September 12, 2000 10:28 AM To: Shahram Davari Cc: issll@mercury.lcs.mit.edu Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt May be some clarification of flow direction as follows is needed? Sender and Receiver are with respect to the uni-directional packet flow. Downstream = Sender towards Receiver. Upstream = Receiver towards Sender. Path Msg travels from Senders towards Receivers, ResV Msg travels from Receivers towards Senders. Maybe the use of "toward Receivers" and "toward Senders" is more concise? -- Kwok -- At 07:05 AM 9/12/00 -0700, Shahram Davari wrote: >Hi, > >To the author of this draft: > >Nice draft, but I think you have completely mixed up the meanings of >upstream and downstream in your draft. In general the PATH message travels >from upstream to downstream and the RESV message travels from downstream to >upstream. In this draft sometimes this is true but in most cases it is >completely reversed. The way the draft is currently written is not readable. > > >Regards, >-Shahram > > >-----Original Message----- >From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org ] >Sent: Tuesday, September 12, 2000 6:50 AM >Cc: issll@mercury.lcs.mit.edu >Subject: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Integrated Services over Specific Link >Layers Working Group of the IETF. > > Title : Capability Negotiation: The RSVP CAP Object > Author(s) : S. Hamid > Filename : draft-ietf-issll-rsvp-cap-00.txt > Pages : 6 > Date : 11-Sep-00 > >The DCLASS object is proposed in [DCLASS] to represent and carry >Differentiated Services Code Points (DSCPs) within RSVP messages. The >principle use of the DCLASS object is to carry DSCP information >between a DS network and upstream nodes that may wish to mark packets >with DSCP values. A network element in the DS network determines the >value for DSCP which is further carried as a DCLASS object in RSVP >RESV message to the sender host. > >A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-00.txt > >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-issll-rsvp-cap-00.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-issll-rsvp-cap-00.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_001_01C023DA.05908958 Content-Type: text/html; charset="iso-8859-1" RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt
Hi,
 
Here is an example from the abstract:
 
 1) The principle use of the DCLASS object is to carry DSCP information
   between a DS network and upstream nodes that may wish to mark packets
   with DSCP values.
 
 2) There may be situations where the sender host is not capable or may
   not wish to mark the packets. Currently, there is no way for the
   host or network devices to specify their capabilities to the upstream
   nodes.
The first paragraph implies that  the host is upstream of the DS network, while the
second paragraph implies that the DS network is upstream of the node.
 
Regards,
-Shahram
 
 
 
 -----Original Message-----
From: Hamid Syed [mailto:hmsyed@nortelnetworks.com]
Sent: Wednesday, September 20, 2000 3:41 PM
To: 'Shahram Davari'; Kwok-Ho Chan; Shahram Davari
Cc: issll@mercury.lcs.mit.edu
Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt

Thanx Shahram for your comments. Sorry for a late response. I was away for a conference and did not have access to e-mails.

 First of all, my definition of upstream/downstream data flow could be different from what the actual definition is (asyou pointed out) but in terms of draft, i dont think there is inconsistency in the definition usage at different places. I would appreciate if you can point me to the actual locations where inconsistency is felt.

regards

Hamid Syed


    -----Original Message-----
    From:   Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
    Sent:   Tuesday, September 12, 2000 4:49 PM
    To:     Chan, Kwok-Ho [BL60:470:EXCH]; Shahram Davari
    Cc:     issll@mercury.lcs.mit.edu
    Subject:        RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt

    There are two separate issues:

    1) The draft is inconsistent in it uses of upstream and downstream words. In
    some parts of the draft upstream mean sender towards receiver, yet in some
    other part of the draft it means receiver toward sender.

    2) Usually upstream means from sender of data to receiver of data (note it
    is data not control)  and downstream means from receiver of data to sender
    of data.

    The first issue is unacceptable, while the second issue is a definition
    only, and a different definition may be used if stated clearly.

    Regards,
    -Shahram



    -----Original Message-----
    From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com]
    Sent: Tuesday, September 12, 2000 10:28 AM
    To: Shahram Davari
    Cc: issll@mercury.lcs.mit.edu
    Subject: RE: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt


    May be some clarification of flow direction as follows is needed?
    Sender and Receiver are with respect to the uni-directional packet flow.
    Downstream = Sender towards Receiver.
    Upstream = Receiver towards Sender.

    Path Msg travels from Senders towards Receivers,
    ResV Msg travels from Receivers towards Senders.

    Maybe the use of "toward Receivers" and "toward Senders" is
    more concise?

    -- Kwok --

     
    At 07:05 AM 9/12/00 -0700, Shahram Davari wrote:
    >Hi,
    >
    >To the author of this draft:
    >
    >Nice draft, but I think you have completely mixed up the meanings of
    >upstream and downstream in your draft. In general the PATH message travels
    >from upstream to downstream and the RESV message travels from downstream to
    >upstream. In this draft sometimes this is true but in most cases it is
    >completely reversed. The way the draft is currently written is not
    readable.
    >
    >
    >Regards,
    >-Shahram
    >
    >
    >-----Original Message-----
    >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
    >Sent: Tuesday, September 12, 2000 6:50 AM
    >Cc: issll@mercury.lcs.mit.edu
    >Subject: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt
    >
    >
    >A New Internet-Draft is available from the on-line Internet-Drafts
    >directories.
    >This draft is a work item of the Integrated Services over Specific Link
    >Layers Working Group of the IETF.
    >
    >       Title           : Capability Negotiation: The RSVP CAP Object
    >       Author(s)       : S. Hamid
    >       Filename        : draft-ietf-issll-rsvp-cap-00.txt
    >       Pages           : 6
    >       Date            : 11-Sep-00
    >      
    >The DCLASS object is proposed in [DCLASS] to represent and carry
    >Differentiated Services Code Points (DSCPs) within RSVP messages. The
    >principle use of the DCLASS object is to carry DSCP information
    >between a DS network and upstream nodes that may wish to mark packets
    >with DSCP values. A network element in the DS network determines the
    >value for DSCP which is further carried as a DCLASS object in RSVP
    >RESV message to the sender host.
    >
    >A URL for this Internet-Draft is:
    >http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-00.txt
    >
    >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-issll-rsvp-cap-00.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-issll-rsvp-cap-00.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_001_01C023DA.05908958-- From owner-issll@mercury.lcs.mit.edu Mon Sep 25 18:27:21 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16235 for ; Mon, 25 Sep 2000 18:27:17 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA09983 for issll-outgoing; Mon, 25 Sep 2000 17:04:05 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA10148 for ; Mon, 25 Sep 2000 17:04:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14011; Mon, 25 Sep 2000 17:03:47 -0400 (EDT) Message-Id: <200009252103.RAA14011@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: issll@mercury.lcs.mit.edu From: The IESG Subject: Protocol Action: Format of the RSVP DCLASS Object to Proposed Standard Date: Mon, 25 Sep 2000 17:03:47 -0400 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk The IESG has approved the following Internet-Drafts as Proposed Standard: o Format of the RSVP DCLASS Object o Specification of the Null Service Type In the same action, the IESG approved publication of A Framework For Integrated Services Operation Over Diffserv Networks as an Informational RFC. These documents are the product of the Integrated Services over Specific Link Layers Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary The Integrated Services architecture provides a means for the delivery of end-to-end QoS to applications over heterogeneous networks. To support this end-to-end model, the Intserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path, and a framework may described on this basis for the support of particular Integrated Services over Diffserv networks, with RSVP playing a key role. RSVP signaling may be used to request QoS services and enhance the manageability of application traffic's QoS in a differentiated service (diffserv or DS) network. When using RSVP with DS networks it is useful to be able to carry Differentiated Services Code Points (DSCPs) in RSVP message objects. One example of this is the use of RSVP to arrange for the marking of packets with a particular DSCP upstream from the DS network's ingress point, at the sender or at a previous network's egress router. The DCLASS object is used to represent and carry DSCPs within RSVP messages. The "Format of the RSVP DCLASS Object" document specifies the format of the DCLASS object and discusses its use. In the typical RSVP/Intserv model, applications request a specific Intserv service type and quantify the resources required for that service. For certain applications, the determination of service parameters is best left to the discretion of the network administrator. For example, Enterprise Resource Planning (ERP) applications are often mission critical, and they often require some form of prioritized service, but may not be able readily to specify their resource requirements. To serve applications of this sort, the notion of the 'Null Service' is defined. The Null Service allows applications to identify themselves to network QoS policy agents, using RSVP signaling, without requiring them to specify their resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service. Working Group Summary The working group supported publication of these three documents, and they also received some discussion by the related WGs, RSVP and Diffserv. Protocol Quality These documents were reviewed for the IESG by Allison Mankin.