From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 02 22:52:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMGR4-000247-Eo for forces-archive@megatron.ietf.org; Sun, 02 Oct 2005 22:52:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14575 for ; Sun, 2 Oct 2005 22:52:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMGZO-0000NU-RX for forces-archive@IETF.ORG; Sun, 02 Oct 2005 23:00:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.01102265@cherry.ease.lsoft.com>; 2 Oct 2005 22:52:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87054632 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 2 Oct 2005 22:51:59 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 2 Oct 2005 22:51:59 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9322PXK004094 for ; Sun, 2 Oct 2005 19:02:26 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1128307916.6531.16.camel@localhost.localdomain> Date: Sun, 2 Oct 2005 22:51:55 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: grammar section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Folks, 1) I would like to propose renaming: DATARAW to Sparse-data and PACKED-DATARAW to Full-data since they sound more descriptive. Recall DATARAW may contain optionally appearing elements and PACKED-DATARAW is when all elements appear but not in ILVs. Any objections or better descriptions? 2) isnt the KEY_DATA a DATA-TLV? i.e could be full or sparse? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 02 23:05:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMGe0-0007Vr-6y for forces-archive@megatron.ietf.org; Sun, 02 Oct 2005 23:05:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14919 for ; Sun, 2 Oct 2005 23:05:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMGmK-0000bQ-R4 for forces-archive@IETF.ORG; Sun, 02 Oct 2005 23:14:17 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.011023B9@cherry.ease.lsoft.com>; 2 Oct 2005 23:05:31 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87056021 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 2 Oct 2005 23:05:30 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 2 Oct 2005 23:05:30 -0400 Received: from [71.240.231.187] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12644829 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 02 Oct 2005 21:05:11 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1128307916.6531.16.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051002230327.03047db0@localhost> Date: Sun, 2 Oct 2005 23:05:21 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: grammar section To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1128307916.6531.16.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d I have no problem with change 1. Key-data is always a perfectly packed field with no options. It does not need an extra TLV, as its length is specified by the wrapper. It does however require the same mapping as the full-data, as there can be variable length fields. (It is tempting to restrict key fields to being fixed length, but that is probably not justifiable.) Yours, Joel At 10:51 PM 10/2/2005, Jamal Hadi Salim wrote: >Folks, > >1) I would like to propose renaming: >DATARAW to Sparse-data >and >PACKED-DATARAW to Full-data > >since they sound more descriptive. >Recall DATARAW may contain optionally appearing elements >and PACKED-DATARAW is when all elements appear but not in ILVs. > >Any objections or better descriptions? > >2) isnt the KEY_DATA a DATA-TLV? i.e could be full or sparse? > > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 03 07:05:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMO8D-0006ld-MY for forces-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20536 for ; Mon, 3 Oct 2005 07:05:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMOGc-0003NL-4i for forces-archive@IETF.ORG; Mon, 03 Oct 2005 07:14:02 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.01102914@cherry.ease.lsoft.com>; Mon, 3 Oct 2005 7:05:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87074193 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 3 Oct 2005 07:05:11 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 3 Oct 2005 07:05:10 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j93AFTXK007687 for ; Mon, 3 Oct 2005 03:15:30 -0700 (PDT) References: <1128307916.6531.16.camel@localhost.localdomain> <6.2.1.2.0.20051002230327.03047db0@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1128337504.6531.19.camel@localhost.localdomain> Date: Mon, 3 Oct 2005 07:05:04 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: grammar section To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20051002230327.03047db0@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit On Sun, 2005-02-10 at 23:05 -0400, Joel M. Halpern wrote > Key-data is always a perfectly packed field with no options. It does not > need an extra TLV, as its length is specified by the wrapper. Ok, so full-data then. > It does however require the same mapping as the full-data, as there can be > variable length fields. (It is tempting to restrict key fields to being > fixed length, but that is probably not justifiable.) I would say full-data then - is that agreeable? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 03 07:07:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMO9z-00079Q-Ur for forces-archive@megatron.ietf.org; Mon, 03 Oct 2005 07:07:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20655 for ; Mon, 3 Oct 2005 07:07:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMOIR-0003Qb-S2 for forces-archive@IETF.ORG; Mon, 03 Oct 2005 07:15:53 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0110283C@cherry.ease.lsoft.com>; Mon, 3 Oct 2005 7:07:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87074230 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 3 Oct 2005 07:07:05 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 3 Oct 2005 07:07:05 -0400 Received: from [71.240.231.187] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12645114 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 03 Oct 2005 05:06:45 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1128307916.6531.16.camel@localhost.localdomain> <6.2.1.2.0.20051002230327.03047db0@localhost> <1128337504.6531.19.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051003070644.03030240@localhost> Date: Mon, 3 Oct 2005 07:07:00 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: grammar section To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1128337504.6531.19.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Sounds good to me. Joel At 07:05 AM 10/3/2005, Jamal Hadi Salim wrote: >On Sun, 2005-02-10 at 23:05 -0400, Joel M. Halpern wrote > > > Key-data is always a perfectly packed field with no options. It does not > > need an extra TLV, as its length is specified by the wrapper. > >Ok, so full-data then. > > > It does however require the same mapping as the full-data, as there can be > > variable length fields. (It is tempting to restrict key fields to being > > fixed length, but that is probably not justifiable.) > >I would say full-data then - is that agreeable? > >cheers, >jamal From LindaYbarra@anorexbu.com Wed Oct 05 09:26:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9Hg-0000Yo-PG for forces-archive@megatron.ietf.org; Wed, 05 Oct 2005 09:26:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22949 for ; Wed, 5 Oct 2005 09:26:10 -0400 (EDT) Received: from [221.126.253.26] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EN9Ou-0003iz-St for forces-archive@ietf.org; Wed, 05 Oct 2005 09:35:24 -0400 Received: from nbeR@localhost by mDtK.int (8.11.6/8.11.6); Wed, 05 Oct 2005 07:35:11 -0700 Message-ID: From: "Ursula Mahoney" Reply-To: "Ursula Mahoney" To: forces-archive@ietf.org Subject: MS Office XP Pro $49.95 Macromedia Date: Wed, 05 Oct 2005 09:39:11 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LindaYbarra@anorexbu.com Content-Type: multipart/mixed; boundary="--ljMjEW4AzcuT21C" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 x5A ----ljMjEW4AzcuT21C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable a
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: rmocYoz
 

Sales Ra= nk: #1
System requirements  |  = Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Rev= iew:3D"5 Based on 1261 reviews. Wr= ite a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: OPByqlGnV
 = ;

Sales Rank: #2
System requirements&nbs= p; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 1446 = reviews. Write a review.

=

= Microsoft Windows XP Professional or Longhorn Edition<= br> Microsoft

Choose:=
 

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)



Availabi= lity: Available for INSTANT download!
Coupon Code: 4HwYqWPc= s
 

Sales Rank: #3<= span class=3Dsmall>
System requireme= nts  |  Other Versions=
Date Coupon Expires: August 31st, 20= 05
Average Customer Review:3D"5 B= ased on 13556 reviews. Write a review.

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: DsBRh3fEY
 = ;

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 1526 = reviews. Write a review.

=

----ljMjEW4AzcuT21C-- From LindaYbarra@anorexbu.com Wed Oct 05 09:27:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9Ir-0001RE-Jt for forces-archive@megatron.ietf.org; Wed, 05 Oct 2005 09:27:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23095 for ; Wed, 5 Oct 2005 09:27:23 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN9RZ-0003qY-Vf for forces-archive@ietf.org; Wed, 05 Oct 2005 09:36:37 -0400 Received: from [221.153.197.227] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EN8RH-0007MF-Jv for forces-archive@ietf.org; Wed, 05 Oct 2005 08:32:04 -0400 Received: from nbeR@localhost by mDtK.int (8.11.6/8.11.6); Wed, 05 Oct 2005 07:35:11 -0700 Message-ID: From: "Ursula Mahoney" Reply-To: "Ursula Mahoney" To: forces-archive@ietf.org Subject: MS Office XP Pro $49.95 Macromedia Date: Wed, 05 Oct 2005 09:39:11 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LindaYbarra@anorexbu.com Content-Type: multipart/mixed; boundary="--ljMjEW4AzcuT21C" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 x5A ----ljMjEW4AzcuT21C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable a
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: rmocYoz
 

Sales Ra= nk: #1
System requirements  |  = Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Rev= iew:3D"5 Based on 1261 reviews. Wr= ite a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: OPByqlGnV
 = ;

Sales Rank: #2
System requirements&nbs= p; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 1446 = reviews. Write a review.

=

= Microsoft Windows XP Professional or Longhorn Edition<= br> Microsoft

Choose:=
 

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)



Availabi= lity: Available for INSTANT download!
Coupon Code: 4HwYqWPc= s
 

Sales Rank: #3<= span class=3Dsmall>
System requireme= nts  |  Other Versions=
Date Coupon Expires: August 31st, 20= 05
Average Customer Review:3D"5 B= ased on 13556 reviews. Write a review.

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: DsBRh3fEY
 = ;

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 1526 = reviews. Write a review.

=

----ljMjEW4AzcuT21C-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 10 11:22:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOzUQ-0005fJ-95 for forces-archive@megatron.ietf.org; Mon, 10 Oct 2005 11:22:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25935 for ; Mon, 10 Oct 2005 11:22:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOzeK-0002uG-HV for forces-archive@IETF.ORG; Mon, 10 Oct 2005 11:33:13 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0110A849@cherry.ease.lsoft.com>; Mon, 10 Oct 2005 11:22:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87671835 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Oct 2005 11:22:50 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 10 Oct 2005 11:22:50 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9AFMoJ6031627; Mon, 10 Oct 2005 15:22:50 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9AFLnbN003026; Mon, 10 Oct 2005 15:22:50 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101008224922296 ; Mon, 10 Oct 2005 08:22:49 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 08:22:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Call for Agenda Items, ForCES Meeting at IETF 64 Thread-Index: AcXNrniqEI+3Fok0QnqHKKO9qyvRzA== X-OriginalArrivalTime: 10 Oct 2005 15:22:49.0755 (UTC) FILETIME=[79921EB0:01C5CDAE] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Putzolu, David" Message-ID: Date: Mon, 10 Oct 2005 08:22:48 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Call for Agenda Items, ForCES Meeting at IETF 64 Comments: cc: Patrick Droz To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable All, The ForCES working group is currently scheduled to meet at IETF 64 on Tuesday, November 8 from 1300-1500. Please email agenda time requests to myself and Patrick and include the following information: * Title of presentation or discussion * Expected duration * Presenter name * Related draft(s) * Any slides or other related materials Thanks, David & Patrick From owner-forces@PEACH.EASE.LSOFT.COM Tue Oct 11 09:03:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPJnP-000619-IH for forces-archive@megatron.ietf.org; Tue, 11 Oct 2005 09:03:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21820 for ; Tue, 11 Oct 2005 09:03:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPJxW-0008JM-Hl for forces-archive@IETF.ORG; Tue, 11 Oct 2005 09:14:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0110B9D7@cherry.ease.lsoft.com>; Tue, 11 Oct 2005 9:03:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87742352 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Oct 2005 09:03:53 -0400 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 11 Oct 2005 09:03:52 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j9BD3qon150986 for ; Tue, 11 Oct 2005 13:03:52 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9BD3pHT139332 for ; Tue, 11 Oct 2005 15:03:51 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j9BD3plJ011607 for ; Tue, 11 Oct 2005 15:03:51 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j9BD3pKP011599 for ; Tue, 11 Oct 2005 15:03:51 +0200 Received: from [127.0.0.1] (dhcp69-217.zurich.ibm.com [9.4.69.217]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA36648 for ; Tue, 11 Oct 2005 15:03:50 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id j9BD3qon150986 Approved-By: Robert Haas Message-ID: <434BB83B.5050100@zurich.ibm.com> Date: Tue, 11 Oct 2005 15:03:55 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: ForCES MIB: 1st draft To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable All, I'm currently putting together a first draft of the ForCES MIB (a=20 requirement to proceed with our protocol draft), and will submit it it=20 by Monday. Below are the major points, please comment. The ForCES MIB is a read-only MIB used to monitor the state of=20 associations in an NE. For each association identified by the pair CE ID=20 and FE ID, the following information is shown: - Current state of the association: UP: the CE(s) indicated by the CE ID and FE(s) indicated by=20 the FE ID are associated. DOWN: the CE(s) indicated by the CE ID and FE(s) indicated by the=20 FE ID are not associated AND the CE(s) indicated by the CE ID is sending=20 Association Setup messages. Note that associations that are DOWN and for which no Association Setup=20 messages are being sent by the CE are NOT listed in the MIB (otherwise=20 how do we decide which old associations to remove from the MIB ?) - Association history: Date/time when the association came to the UP state. (Number of commands executed or some indications of the ForCES=20 control traffic ?) - Hearbeat timers values of the FE and CE for this association. - Heartbeat timer settings of the FE and CE for this association:=20 ENABLED: hearbeats are transmitted (by default virtual piggybacking=20 is used) DISABLED: heartbeats are not transmitted =20 - Backup information: the FE(s)/CE(s) that are configured to work as=20 backups for this association (necessary ? useful ?) Regards, --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 11:37:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPifo-0006KY-55 for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 11:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28949 for ; Wed, 12 Oct 2005 11:37:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPiq5-0006Cx-3Q for forces-archive@IETF.ORG; Wed, 12 Oct 2005 11:48:25 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0110D116@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 11:37:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87844906 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 11:37:29 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 11:37:28 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9CEjfXK020900 for ; Wed, 12 Oct 2005 07:45:42 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-niPIXDg7M7HwK01T89/w" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129131446.7045.12.camel@localhost.localdomain> Date: Wed, 12 Oct 2005 11:37:26 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: HA section effect on overview To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --=-niPIXDg7M7HwK01T89/w Content-Type: text/plain Content-Transfer-Encoding: 7bit I have made the change outlined in the diff based on the new agreed mods to HA. Please comment/nod/hum/whistle. Weiming, If you have time send me text on the HB message and agreed to text with the HA mods. Otherwise i will get to it in the near future. Sorry, I was busy and didnt follow the discussion to completion. cheers, jamal --=-niPIXDg7M7HwK01T89/w Content-Disposition: attachment; filename=ov-ha.txt Content-Type: text/plain; name=ov-ha.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit --- draft-ietf-forces-protocol.txt-old 2005-09-23 13:37:40.000000000 -0400 +++ draft-ietf-forces-protocol.txt 2005-10-11 22:30:37.000000000 -0400 @@ -971,15 +971,6 @@ association is dictated by the CE Failover policy (refer to Section 8 and Section 6.2). - In the case of desire to do HA then multiple associations would exist - between the FE and multiple CEs although only one of them would be - the master at any time (as described in Section 8). The CEs to which - the FE is associated to would need to be synchronized on the state of - the FE. The scheme for such a synchronization is outside the scope - of ForCES but is mentioned here to indicate that in such a setup, the - FE would not be re-associating itself to the new CE master and would - therefore not need to reload its state from scratch. - 3.3.1.1.5. continue-execute-on-failure In which several independent operations are targeted at one or more --=-niPIXDg7M7HwK01T89/w-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 12:15:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjGN-00072O-Eg for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 12:15:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02961 for ; Wed, 12 Oct 2005 12:15:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPjQd-0007vb-Ov for forces-archive@IETF.ORG; Wed, 12 Oct 2005 12:26:13 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0110D109@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 12:15:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87846526 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 12:15:13 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 12:15:12 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9CFNNXK021350 for ; Wed, 12 Oct 2005 08:23:24 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-TOgG/83cbRyGpyZxcH14" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129133707.7045.19.camel@localhost.localdomain> Date: Wed, 12 Oct 2005 12:15:07 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: section 6.1 grammar update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c2c13da073bbdd073b64ce7ea2347217 --=-TOgG/83cbRyGpyZxcH14 Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks, Please review this closely. Joel - if you can pay close attention to this I would appreciate it. There has been some major updates to sync with other sections etc. I will follow up with the use cases appendix to reflect accurately the details shown. All the text in the rest of section 6 needs to be synchronized with this section. Its more of mechanical time consuming work i.e nothing to discuss really. I wont have time to touch that today. cheers, jamal --=-TOgG/83cbRyGpyZxcH14 Content-Disposition: attachment; filename=sec-6.1.txt Content-Type: text/plain; name=sec-6.1.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 6. Protocol Construction 6.1. Protocol Grammar The protocol construction is formally defined using a BNF-like syntax to describe the structure of the PDU layout. This is matched to a precise binary format later in the document. Since the protocol is very flexible and hierachical in nature, it is easier at times to see the visualization layout. This is provided in Section 6.1.2 6.1.1. Protocol BNF The format used is based on RFC 2234. The terminals of this gramar are flags, IDcount, IDs, KEYID, and encoded data, described after the grammar. 1. A TLV will have the word "-TLV" suffix at the end of its name 2. An ILV will have the word "-ILV" suffix at the end of its name 3. / is used to separate alternatives 4. parenthesised elements are treated as a single item 5. * before an item indicates 0 or more repetitions 6. 1* before an item indicates 1 or more repetitions 7. [] around an item indicates that it is optional (equal to *0) The BNF of the PL level PDU is as follows: Doria (Ed.), et al. Expires February 2, 2006 [Page 30] Internet-Draft ForCES August 2005 PL level PDU := MAINHDR [MAIN-TLV] MAIN-TLV := [LFBselect-TLV] / [REDIRECT-TLV] / [ASResult-TLV] / [ASTreason-TLV] LFBselect-TLV := LFBCLASSID LFBInstance OPER-TLV OPER-TLV := 1*PATH-DATA-TLV PATH-DATA-TLV := PATH [DATA] PATH := flags IDcount IDs [SELECTOR] SELECTOR := KEYINFO-TLV DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / 1*PATH-DATA-TLV KEYINFO-TLV := KEYID FULLDATA-TLV SPARSEDATA-TLV := encoded data that may have optionally appearing elements FULLDATA-TLV := encoded data element which may nest further FULLDATA-TLVs RESULT-TLV := Holds result code and optional FULLDATA-TLV o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR also defines the content. As an example the content of a "config" message would be different from an "association" message. o MAIN-TLV is one of several TLVs that could follow the Mainheader. The appearance of these TLVs is message type specific. o LFBCLASSID is a 32 bit unique identifier per LFB class defined at class Definition time. o LFBInstance is a 32 bit unique instance identifier of an LFB class o OPER-TLV uses the Type field in the TLV to uniquely identify the type of operation i.e one of {SET, GET, DEL,etc.} depending on the message type. o PATH-DATA-TLV identifies the exact element targeted and may have zero or more paths associated with it. The last PATH-DATA-TLV in the case of nesting of paths via the DATA construct is terminated by encoded data or response in the form of either FULLDATA-TLV or SPARSEDATA-TLV or RESULT-TLV. o PATH provides the path to the data being referenced. * flags (16 bits) are used to further refine the operation to be applied on the Path. More on these later. * IDcount(16 bit): count of 32 bit IDs Doria (Ed.), et al. Expires February 2, 2006 [Page 31] Internet-Draft ForCES August 2005 * IDs: zero or more 32bit IDs (whose count is given by IDcount) defining the main path. Depending on the flags, IDs could be field IDs only or a mix of field and dynamic IDs. Zero is used for the special case of using the entirety of the containing context as the result of the path. o SELECTOR is an optional construct that further defines the PATH. Currently, the only defined selector is the KEYINFO-TLV, used for selecting an array entry by the value of a key field. The presence of a SELECTOR is correct only when the flags also indicate its presence. A mismatch is a protocol format error. o A KEYINFO TLV contains information used in content keying. * A KeyID is used in a KEYINFO TLV. It indicates which key for the current array is being used as the content key for array entry selection. * The key's data is the data to look for in the array, in the fields identified by the keyfield. The information is encoded according to the rules for the contents of a FULLDATA-TLV, and represent the field or fields which make up the key identified by the KEYID. o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV or 1 or more further PATH-DATA selection. FULLDATA and SPARSEDATA are only allowed on SET requests, or on responses which return content information (GET-RESPONSE for example). PATH-DATA may be included to extend the path on any request. * Note: Nested PATH-DATA TLVs are supported as an efficiency measure to permit common subexpression extraction. * FULLDATA and SPARSEDATA contain "the data" whose path has been selected by the PATH. Refer to Section 6.1.1.1 for details. o RESULT contains the indication of whether the individual SET succeeded. If there is an indication for verbose response, then SET-RESPONSE will also contain the FULLDATA TLV showing the data that was set. RESULT-TLV is included on the assumption that individual parts of a SET request can succeed or fail separately. In summary this approach has the following characteristic: o There can be one or more LFB Class + InstanceId combo targeted in a message (batch) Doria (Ed.), et al. Expires February 2, 2006 [Page 32] Internet-Draft ForCES August 2005 o There can one or more operations on an addressed LFB classid+ instanceid combo(batch) o There can be one or more path targets per operation (batch) o Paths may have zero or more data values associated (flexibility and operation specific) It should be noted that the above is optimized for the case of a single classid+instance targeting. To target multiple instances within the same class, multiple LFBselect are needed. 6.1.1.1. Discussion on Grammar In the case of FULLDATA encoding, data is packed in such a way that a receiver of such data with knowledge of the path can correlate what it means by infering in the LFB definition. This is an optimization that helps reducing the amount of description for the data in the protocol. In other words: It is assumed that the type of the data can be inferred by the context in which data is used. Hence, data will not include its type information. The basis for the inference is typically the LFB class id and the path. It is expected that a substantial amount of operations in ForCES will need to reference optional data within larger structures. For this reason, the SPARSEDATA encoding is introduced to make it easier to encapsulate optionaly appearing data elements. 6.1.1.1.1. Data Packing Rules The scheme for encoding data used in this doc adheres to the following rules: o The Value ("V" of TLV) of FULLDATA TLV will contain the data being transported. This data will be as was described in the LFB definition. * As an example a 16 bit value within a TLV will have an extra 16 bit pad; however two 16 bits values in another TLV structure will be shipped together with no padding etc. o Variable sized data within a FULLDATA TLV will be encapsulated inside another FULLDATA TLV inside the V of the outer TLV. For example of this see Appendix E example 13. Doria (Ed.), et al. Expires February 2, 2006 [Page 33] Internet-Draft ForCES August 2005 o In the case of PACKEDDATA TLVs: o When a table is refered to in the PATH (ids) of a PATH-DATA-TLV, then the PACKEDDATA's "V" will contain that table's row content prefixed by its 32 bit index/subscript. OTOH, when PATH flags are 00, the PATH may contain an index pointing to a row in table; in such a case, the PACKEDDATA's "V" will only contain the content with the index in order to avoid ambiguity. 6.1.1.1.2. Path Flags The following flags are currently defined: o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present following this path information, and should be considered in evaluating the path. o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set. This must only be used on a create operation. If set, this indicates that although the path identifies an array, the SET operation should be applied to the first unused element in the array. The result of the operation will not have this flag set, and will have the assigned index in the path. 6.1.1.1.3. Relation of operational flags with global message flags Should be noted that other applicable flags such as atomicity indicators as well as verbosity result formaters are in the main headers flags area. 6.1.1.1.4. Content Path Selection The KEYINFO TLV describes the KEY as well as associated KEY data. KEYs, used for content searches, are restricted and described in the LFB definition. 6.1.1.1.5. LFB select TLV The LFB select TLV is an instance of TLV defined in Section 5.2. The definition is as below: Doria (Ed.), et al. Expires February 2, 2006 [Page 34] Internet-Draft ForCES August 2005 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = LFBselect | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 Type: The type of the TLV is "LFBselect" Length: Length of the TLV including the T and L fields, in bytes. LFB Class ID: This field uniquely recognizes the LFB class/type. LFB Instance ID: This field uniquely identifies the LFB instance. Operation TLV: It describes an operation nested in the LFB select TLV. Note that usually there SHOULD be at least one Operation TLV present for an LFB select TLV, but for Association Setup Message defined in Section 6.4.1, Operation TLV is totally optional, therefore there might be no any Operation TLV followed in the LFB select TLV there. 6.1.1.1.6. Operation TLV The Operation TLV is an instance of TLV Idefined in Section 5.2. It is assumed that specific operations are identified by the Type code of the TLV. Definitions for individual Types of operation TLVs are in corresponding message description sections followed. Doria (Ed.), et al. Expires February 2, 2006 [Page 35] Internet-Draft ForCES August 2005 6.1.1.1.7. Result TLV A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 byte) value. The defined values are 0 = success 1 = no such object 2 = permission denied 3 = invalid value (the dataraw could not validly be stored in the field) 4 = invalid array creation (when the subscript in an array create is not allowed) 255 = unspecified error (for when the FE can not decide what went wrong) SET and GET Requests do not have result information (they are requests). SET and GET Responses have result information. SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. For a GET responses, individual gets which succeed will have FULLDATA TLVs added to the leaf paths to carry the requested data. For GET elements that fail, instead of the FULLDATA TLV there will be a RESULT TLV. For a SET response, each FULLDATA TLV in the original request will be replace with a RESULT TLV in the response. If the request was for Ack-fail, then only those items which failed will appear in the response. If the request was for ack-all, then all elements of the request will appear in the response with RESULT TLVs. Note that if a SET request with a structure in a FULLDATA is issued, and some field in the structure is invalid, the FE will not attempt to indicate which field was invalid, but rather will indicate that the operation failed. Note further that if there are multiple errors in a single leaf path-data / FULLDATA, the FE can select which error it chooses to return. So if a FULLDATA for a SET of a structure attempts to write one field which is read only, and attempts to set another field to an invalid value, the FE can return whatever error it likes. Doria (Ed.), et al. Expires February 2, 2006 [Page 36] Internet-Draft ForCES August 2005 6.1.1.1.8. DATA TLV A FULLDATA TLV has "T"= FULLDATA, and a 16bit Length followed by the data value/contents. Likewise, a SPARSEDATA TLV has "T" = SPARSEDATA, a 16bit Length followed by the data value/contents. In the case of the SPARSEDATA each element in the Value part of the TLV will be further encapsulated in an ILV. Rules: 1. Both ILVs and TLVs MUST 32 bit aligned. If need be they SHOULD be padded to achieve the alignement. 2. FULLDATA TLV may be used at a particular path only if every element at that path level is present. This requirement holds whether the fields are fixed or variable length, mandatory or optional. * If a FULLDATA TLV is used, the encoder MUST layout data for each element ordered by the order in which the data was defined in the LFB specification. This ensures the decoder is guaranteed to retrieve the data. * In the case of a SPARSEDATA we dont need to order since the "I" in the ILV uniquely identifies the element. 3. Inside a FULLDATA TLV * The values for atomic, fixed-length fields are given without any TLV or ILV encapsulation. * The values for atomic, variable-length fields are given inside FULLDATA TLVs. 4. Inside a SPARSE TLV * the values for atomic fields may be given with ILVs (32-bit index, 32-bit length) 5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot contain a FULLDATA. This is because it is hard to disambiguate ILV since an I is 32 bit and a T is 16 bit. 6. A FULLDATA can also contain a FULLDATA for variable sized elements. The decoding disambiguation is assumed from rule #3 above. Doria (Ed.), et al. Expires February 2, 2006 [Page 37] Internet-Draft ForCES August 2005 6.1.1.1.9. SET and GET Relationship It is expected that a GET-RESPONSE would satisfy the following desires: o it would have exactly the same path definitions as that was sent in the GET. The only difference being a GET-RESPONSE will contain FULLDATA TLVs. o it should be possible that one would take the same GET-RESPONSE and convert it to a SET-REPLACE successfully by merely changing the T in the operational TLV. o There are exceptions to this rule: 1. When a KEY selector is used with a path in a GET operation, that selector is not returned in the GET-RESPONSE; instead the cooked result is returned. Refer to the examples using KEYS to see this. 2. When dumping a whole table in a GET, the GET-RESPONSE, merely editing the T to be SET will endup overwritting the table. 6.1.2. Protocol Visualization The figure below shows a general layout of the PL PDU. A main header is followed by one or more LFB selections each of which may contain one or more operation. Doria (Ed.), et al. Expires February 2, 2006 [Page 38] Internet-Draft ForCES August 2005 main hdr (Config in this case) | | +--- T = LFBselect | | | +-- LFBCLASSID | | | | | +-- LFBInstance | | | +-- T = SET-CREATE | | | | | +-- // one or more path targets | | // with their data here to be added | | | +-- T = DEL | . | | . +-- // one or more path targets to be deleted | | +--- T = LFBselect | | | +-- LFBCLASSID | | | | | +-- LFBInstance | | | + -- T= SET-REPLACE | | | | | + -- T= DEL | | | + -- T= SET-REPLACE | | +--- T = LFBselect | +-- LFBCLASSID | +-- LFBInstance . . . Figure 12: PL PDU layout Doria (Ed.), et al. Expires February 2, 2006 [Page 39] Internet-Draft ForCES August 2005 The figure below shows an example general layout of the operation within a targetted LFB selection. The idea is to show the different nesting levels a path could take to get to the target path. T = SET-CREATE | | | +- T = Path-data | | | + -- flags | + -- IDCount | + -- IDs | | | +- T = Path-data | | | + -- flags | + -- IDCount | + -- IDs | | | +- T = Path-data | | | + -- flags | + -- IDCount | + -- IDs | + -- T = KEYINFO | | + -- KEY_ID | | + -- KEY_DATA | | | + -- T = FULLDATA | + -- data | | T = SET-REPLACE | | | +- T = Path-data | | | | | + -- flags | | + -- IDCount | | + -- IDs | | | | | + -- T = FULLDATA | | + -- data | +- T = Path-data | | | + -- flags | + -- IDCount | + -- IDs Doria (Ed.), et al. Expires February 2, 2006 [Page 40] Internet-Draft ForCES August 2005 | | | + -- T = FULLDATA | + -- data T = DEL | +- T = Path-data | + -- flags + -- IDCount + -- IDs | +- T = Path-data | + -- flags + -- IDCount + -- IDs | +- T = Path-data | + -- flags + -- IDCount + -- IDs + -- T = KEYINFO | + -- KEY_ID | + -- KEY_DATA +- T = Path-data | + -- flags + -- IDCount + -- IDs Figure 13: Sample operation layout --=-TOgG/83cbRyGpyZxcH14-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 12:53:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjqz-000316-Oh for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 12:53:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05064 for ; Wed, 12 Oct 2005 12:53:17 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPk1G-0000Ye-EC for forces-archive@IETF.ORG; Wed, 12 Oct 2005 13:04:03 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0110D0FC@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 12:53:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87848017 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 12:52:56 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 12:52:54 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9CG16XK021788 for ; Wed, 12 Oct 2005 09:01:06 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-QOVtHX9dOYyq4MP/Dj2w" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129135971.7045.24.camel@localhost.localdomain> Date: Wed, 12 Oct 2005 12:52:51 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: use cases appendix To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a987b7da29619ee1a2707473847f98e --=-QOVtHX9dOYyq4MP/Dj2w Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, attached is the appendix to match section 6.1. I need a pair of eyes or more to scan it for obvious errors. cheers, jamal --=-QOVtHX9dOYyq4MP/Dj2w Content-Disposition: attachment; filename=use-cases.txt Content-Type: text/plain; name=use-cases.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Appendix E. Use Cases Assume LFB with following attributes for the following use cases. foo1, type u32, ID = 1 foo2, type u32, ID = 2 table1: type array, ID = 3 elements are: t1, type u32, ID = 1 t2, type u32, ID = 2 // index into table 2 KEY: nhkey, ID = 1, V = t2 table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 KEY: akey, ID = 1, V = { j1,j2 } table3: type array, ID = 5 elements are: someid, type u32, ID = 1 name, type string variable sized, ID = 2 table4: type array, ID = 6 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 j3, type u32, ID = 3 j4, type u32, ID = 4 KEY: mykey, ID = 1, V = { j1} table5: type array, ID = 7 elements are: p1, type u32, ID = 1 p2, type array, ID = 2, array elements of type-X Type-X: x1, ID 1, type u32 x2, ID2 , type u32 KEY: tkey, ID = 1, V = { x1} All examples will show an attribute suffixed with "v" or "val" to Doria (Ed.), et al. Expires February 2, 2006 [Page 86] Internet-Draft ForCES August 2005 indicate the value of the referenced attribute. example for attribute foo2, foo1v or foo1value will indicate the value of foo1. In the case where F_SEL** are missing (bits equal to 00) then the flags will not show any selection. 1. To get foo1 OPER = GET-TLV Path-data TLV: IDCount = 1, IDs = 1 Result: OPER = GET-RESPONSE-TLV Path-data-TLV: flags=0, IDCount = 1, IDs = 1 DATARAW-TLV L = 4+4, V = foo1v 2. To set foo2 to 10 OPER = SET-REPLACE-TLV Path-data-TLV: flags = 0, IDCount = 1, IDs = 2 DATARAW TLV: L = 4+4, V=10 Result: OPER = SET-RESPONSE-TLV Path-data-TLV: flags = 0, IDCount = 1, IDs = 2 RESULT-TLV 3. To dump table2 OPER = GET-TLV Path-data-TLV: IDCount = 1, IDs = 4 Result: OPER = GET-RESPONSE-TLV Path-data-TLV: flags = 0, IDCount = 1, IDs = 4 DATARAW=TLV: L = XXX, V= a series of: index, j1value,j2value entries representing the entire table 4. Note: One should be able to take a GET-RESPONSE-TLV and convert it to a SET-REPLACE-TLV. If the result in the above example is sent back in a SET-REPLACE-TLV, (instead of a GET-RESPONSE_TLV) Doria (Ed.), et al. Expires February 2, 2006 [Page 87] Internet-Draft ForCES August 2005 then the entire contents of the table will be replaced at that point. 5. Multiple operations Example. To create entry 0-5 of table2 (Ignore error conditions for now) Doria (Ed.), et al. Expires February 2, 2006 [Page 88] Internet-Draft ForCES August 2005 OPER = SET-CREATE-TLV Path-data-TLV: flags = 0 , IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 DATARAW-TLV containing j1, j2 value for entry 0 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 1 DATARAW-TLV containing j1, j2 value for entry 1 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 DATARAW-TLV containing j1, j2 value for entry 2 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 DATARAW-TLV containing j1, j2 value for entry 3 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 4 DATARAW-TLV containing j1, j2 value for entry 4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 5 DATARAW-TLV containing j1, j2 value for entry 5 Result: OPER = SET-RESPONSE-TLV Path-data-TLV: flags = 0 , IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 4 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 5 RESULT-TLV Doria (Ed.), et al. Expires February 2, 2006 [Page 89] Internet-Draft ForCES August 2005 6. Block operations (with holes) example. Replace entry 0,2 of table2 OPER = SET-REPLACE-TLV Path-data TLV: flags = 0 , IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 DATARAW-TLV containing j1, j2 value for entry 0 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 DATARAW-TLV containing j1, j2 value for entry 2 Result: OPER = SET-REPLACE-TLV Path-data TLV: flags = 0 , IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV 7. Getting rows example. Get first entry of table2. OPER = GET-TLV Path-data TLV: IDCount = 2, IDs=4.0 Result: OPER = GET-RESPONSE-TLV Path-data TLV: IDCount = 2, IDs=4.0 DATARAW TLV, Length = XXX, V = j1value,j2value entry 8. Get entry 0-5 of table2. Doria (Ed.), et al. Expires February 2, 2006 [Page 90] Internet-Draft ForCES August 2005 OPER = GET-TLV Path-data-TLV: flags = 0, IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 1 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 5 Result: OPER = GET-RESPONSE-TLV Path-data-TLV: flags = 0, IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 DATARAW-TLV containing j1value j2value PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 1 DATARAW-TLV containing j1value j2value PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 DATARAW-TLV containing j1value j2value PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 DATARAW-TLV containing j1value j2value PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 4 DATARAW-TLV containing j1value j2value PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 5 DATARAW-TLV containing j1value j2value 9. Create a row in table2, index 5. Doria (Ed.), et al. Expires February 2, 2006 [Page 91] Internet-Draft ForCES August 2005 OPER = SET-CREATE-TLV Path-data-TLV: flags = 0, IDCount = 2, IDs=4.5 DATARAW TLV, Length = XXX j1value,j2value Result: OPER = SET-RESPONSE-TLV Path-data TLV: flags = 0, IDCount = 1, IDs=4.5 RESULT-TLV 10. An example of "create and give me an index" Assuming we asked for verbose response back in the main message header. OPER = SET-CREATE-TLV Path-data -TLV: flags = FIND-EMPTY, IDCount = 1, IDs=4 DATARAW TLV, Length = XXX j1value,j2value Result If 7 were the first unused entry in the table: OPER = SET-RESPONSE Path-data TLV: flags = 0, IDCount = 2, IDs=4.7 RESULT-TLV indicating success, and DATARAW-TLV, Length = XXX j1value,j2value 11. Dump contents of table1. OPER = GET-TLV Path-data TLV: flags = 0, IDCount = 1, IDs=3 Result: OPER = GET-RESPONSE-TLV Path-data TLV flags = 0, IDCount = 1, IDs=3 DATARAW TLV, Length = XXXX (depending on size of table1) index, t1value, t2value index, t1value, t2value . Doria (Ed.), et al. Expires February 2, 2006 [Page 92] Internet-Draft ForCES August 2005 . . 12. Using Keys. Get row entry from table4 where j1=100. Recall, j1 is a defined key for this table and its keyid is 1. OPER = GET-TLV Path-data-TLV: flags = F_SELKEY IDCount = 1, IDs=6 KEYINFO-TLV = KEYID=1, KEY_DATA=100 Result: If j1=100 was at index 10 OPER = GET-RESPONSE-TLV Path-data TLV: flags = 0, IDCount = 1, IDs=6.10 DATARAW TLV, Length = XXXX j1value,j2value, j3value, j4value 13. Delete row with KEY match (j1=100, j2=200) in table 2. Note that the j1,j2 pair are a defined key for the table 2. OPER = DEL-TLV Path-data TLV: flags = F_SELKEY IDCount = 1, IDs=4 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} Result: If (j1=100, j2=200) was at entry 15: OPER = DELETE-RESPONSE-TLV Path-data TLV: flags = 0 IDCount = 2, IDs=4.15 RESULT-TLV (with DATARAW if verbose) 14. Dump contents of table3. It should be noted that this table has a column with element name that is variable sized. The purpose of this use case is to show how such an element is to be encoded. Doria (Ed.), et al. Expires February 2, 2006 [Page 93] Internet-Draft ForCES August 2005 OPER = GET-TLV Path-data-TLV: flags = 0 IDCount = 1, IDs=5 Result: OPER = GET-RESPONSE-TLV Path-data TLV: flags = 0 IDCount = 1, IDs=5 DATARAW TLV, Length = XXXX index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev . . . 15. Multiple atomic operations. 16. Note: This emulates adding a new nexthop entry and then atomically updating the L3 entries pointing to an old NH to point to a new one. The assumption is both tables are in the same LFB 17. Main header has atomic flag set and we are request for verbose/ full results back; Two operations on the LFB instance, both are SET operations. Doria (Ed.), et al. Expires February 2, 2006 [Page 94] Internet-Draft ForCES August 2005 //Operation 1: Add a new entry to table2 index #20. OPER = SET-CREATE-TLV Path-TLV: flags = 0, IDCount = 2, IDs=4.20 DATARAW TLV, V= j1value,j2value // Operation 2: Update table1 entry which // was pointing with t2 = 10 to now point to 20 OPER = SET-REPLACE-TLV Path-data-TLV: flags = F_SELKEY, IDCount = 1, IDs=3 KEYINFO = KEYID=1 KEY_DATA=10 Path-data-TLV flags = 0 IDCount = 1, IDs=2 DATARAW TLV, V= 20 Result: //first operation, SET OPER = SET-RESPONSE-TLV Path-data-TLV flags = 0 IDCount = 3, IDs=4.20 RESULT-TLV code = success DATARAW TLV, V = j1value,j2value // second opertion SET - assuming entry 16 was updated OPER = SET-RESPONSE-TLV Path-data TLV flags = 0 IDCount = 2, IDs=3.16 Path-Data TLV flags = 0 IDCount = 1, IDs = 2 SET-RESULT-TLV code = success DATARAW TLV, Length = XXXX v=20 // second opertion SET OPER = SET-RESPONSE-TLV Path-data TLV flags = 0 IDCount = 1, IDs=3 KEYINFO = KEYID=1 KEY_DATA=10 Path-Data TLV flags = 0 IDCount = 1, IDs = 2 SET-RESULT-TLV code = success DATARAW TLV, Length = XXXX v=20 18. Selective setting (Example posted by Weiming). On table 4 -- for indices 1, 3, 5, 7, and 9. Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. PER = SET-REPLACE-TLV Doria (Ed.), et al. Expires February 2, 2006 [Page 95] Internet-Draft ForCES August 2005 Path-data TLV flags = 0, IDCount = 1, IDs = 6 Path-data TLV flags = 0, IDCount = 1, IDs = 1 Path-data TLV flags = 0, IDCount = 1, IDs = 1 DATARAW TLV, Length = XXXX, V = {100} Path-data TLV flags = 0, IDCount = 1, IDs = 2 DATARAW TLV, Length = XXXX, V = {200} Path-data TLV flags = 0, IDCount = 1, IDs = 3 DATARAW TLV, Length = XXXX, V = {300} Path-data TLV flags = 0, IDCount = 1, IDs = 3 Path-data TLV flags = 0, IDCount = 1, IDs = 1 DATARAW TLV, Length = XXXX, V = {100} Path-data TLV flags = 0, IDCount = 1, IDs = 2 DATARAW TLV, Length = XXXX, V = {200} Path-data TLV flags = 0, IDCount = 1, IDs = 3 DATARAW TLV, Length = XXXX, V = {300} Path-data TLV flags = 0, IDCount = 1, IDs = 5 Path-data TLV flags = 0, IDCount = 1, IDs = 1 DATARAW TLV, Length = XXXX, V = {100} Path-data TLV flags = 0, IDCount = 1, IDs = 2 DATARAW TLV, Length = XXXX, V = {200} Path-data TLV flags = 0, IDCount = 1, IDs = 3 DATARAW TLV, Length = XXXX, V = {300} Path-data TLV flags = 0, IDCount = 1, IDs = 7 Path-data TLV flags = 0, IDCount = 1, IDs = 1 DATARAW TLV, Length = XXXX, V = {100} Path-data TLV flags = 0, IDCount = 1, IDs = 2 DATARAW TLV, Length = XXXX, V = {200} Path-data TLV flags = 0, IDCount = 1, IDs = 3 DATARAW TLV, Length = XXXX, V = {300} Path-data TLV flags = 0, IDCount = 1, IDs = 9 Doria (Ed.), et al. Expires February 2, 2006 [Page 96] Internet-Draft ForCES August 2005 Path-data TLV flags = 0, IDCount = 1, IDs = 1 DATARAW TLV, Length = XXXX, V = {100} Path-data TLV flags = 0, IDCount = 1, IDs = 2 DATARAW TLV, Length = XXXX, V = {200} Path-data TLV flags = 0, IDCount = 1, IDs = 3 DATARAW TLV, Length = XXXX, V = {300} Non-verbose response mode shown: OPER = SET-RESPONSE-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 6 Path-data TLV flags = 0, IDCount = 1, IDs = 1 Path-data TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 Path-data TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 5 Path-data TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 Doria (Ed.), et al. Expires February 2, 2006 [Page 97] Internet-Draft ForCES August 2005 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 7 Path-data TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 9 Path-data TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 RESULT-TLV 19. Manipulation of table of table examples. Get x1 from table10 row with index 4, inside table5 entry 10 operation = GET-TLV Path-data-TLV flags = 0 IDCount = 5, IDs=7.10.2.4.1 Results: operation = GET-RESPONSE-TLV Path-data-TLV flags = 0 IDCount = 5, IDs=7.10.2.4.1 DATARAW TLV: L=XXXX, V = {x1 value} 20. From table5's row 10 table10, get X2s based on on the value of x1 equlaing 10 (recal x1 is KeyID 1) Doria (Ed.), et al. Expires February 2, 2006 [Page 98] Internet-Draft ForCES August 2005 operation = GET-TLV Path-data-TLV flag = F_SELKEY, IDCount=3, IDS = 7.10.2 KEYINFO TLV, KEYID = 1, KEYDATA = 10 Path-data TLV IDCount = 1, IDS = 2 //select x2 Results: If x1=10 was at entry 11: operation = GET-RESPONSE-TLV Path-data-TLV flag = 0, IDCount=5, IDS = 7.10.2.11 Path-data TLV flags = 0 IDCount = 1, IDS = 2 DATARAW TLV: L=XXXX, V = {x2 value} 21. Further example of table of table Consider table 6 which is defined as: table6: type array, ID = 8 elements are: p1, type u32, ID = 1 p2, type array, ID = 2, array elements of type type-A type-A: a1, type u32, ID 1, a2, type array ID2 ,array elements of type type-B type-B: b1, type u32, ID 1 b2, type u32, ID 2 So lets say we wanted to set by replacing: table6.10.p1 to 111 table6.10.p2.20.a1 to 222 table6.10.p2.20.a2.30.b1 to 333 in one message and one operation. There are two ways to do this: a) using nesting operation = SET-REPLACE-TLV Path-data-TLV flags = 0 IDCount = 2, IDs=6.10 Path-data-TLV Doria (Ed.), et al. Expires February 2, 2006 [Page 99] Internet-Draft ForCES August 2005 flags = 0, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {111} Path-data-TLV flags = 0 IDCount = 2, IDs=2.20 Path-data-TLV flags = 0, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {222} Path-data TLV : flags = 0, IDCount = 3, IDs=2.30.1 DATARAW TLV: L=XXXX, V = {333} Result: operation = SET-RESPONSE-TLV Path-data-TLV flags = 0 IDCount = 2, IDs=6.10 Path-data-TLV flags = 0, IDCount = 1, IDs=1 RESULT-TLV Path-data-TLV flags = 0 IDCount = 2, IDs=2.20 Path-data-TLV flags = 0, IDCount = 1, IDs=1 RESULT-TLV Path-data TLV : flags = 0, IDCount = 3, IDs=2.30.1 RESULT-TLV b) using a flat path data operation = SET-REPLACE-TLV Path-data TLV : flags = 0, IDCount = 3, IDs=6.10.1 DATARAW TLV: L=XXXX, V = {111} Path-data TLV : flags = 0, IDCount = 5, IDs=6.10.1.20.1 DATARAW TLV: L=XXXX, V = {222} Path-data TLV : flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 DATARAW TLV: L=XXXX, V = {333} Result: operation = SET-REPLACE-TLV Path-data TLV : flags = 0, IDCount = 3, IDs=6.10.1 RESULT-TLV Path-data TLV : Doria (Ed.), et al. Expires February 2, 2006 [Page 100] Internet-Draft ForCES August 2005 flags = 0, IDCount = 5, IDs=6.10.1.20.1 RESULT-TLV Path-data TLV : flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 RESULT-TLV 22. Get a whole LFB (all its attributes etc). 23. For example, at startup a CE might well want the entire FE OBJECT LFB. So, in a request targetted at class 1, instance 1, one might find: operation = GET-TLV Path-data-TLV flags = 0 IDCount = 0 result: operation = GET-RESPONSE-TLV Path-data-TLV flags = 0 IDCount = 0 DATARAW encoding of the FE Object LFB Doria (Ed.), et al. Expires February 2, 2006 [Page 101] Internet-Draft ForCES August 2005 --=-QOVtHX9dOYyq4MP/Dj2w-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 13:00:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjxQ-0004d6-2G for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 13:00:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05385 for ; Wed, 12 Oct 2005 12:59:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPk7k-0000jx-CQ for forces-archive@IETF.ORG; Wed, 12 Oct 2005 13:10:41 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0110D208@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 12:59:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87848399 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 12:59:50 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 12:59:50 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9CG82XK021926 for ; Wed, 12 Oct 2005 09:08:02 -0700 (PDT) References: <1129135971.7045.24.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-/tV1cbbyZk7+7JA6gIQ3" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129136386.7045.27.camel@localhost.localdomain> Date: Wed, 12 Oct 2005 12:59:46 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: use cases appendix To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1129135971.7045.24.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 --=-/tV1cbbyZk7+7JA6gIQ3 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sorry, I posted the wrong text - that text also needs fixing (i forgot about it);i dont have time today. Heres the correct text. cheers, jamal On Wed, 2005-12-10 at 12:52 -0400, Jamal Hadi Salim wrote: > Ok, attached is the appendix to match section 6.1. > I need a pair of eyes or more to scan it for obvious errors. > > cheers, > jamal --=-/tV1cbbyZk7+7JA6gIQ3 Content-Disposition: attachment; filename=examples.txt Content-Type: text/plain; name=examples.txt; charset=utf-8 Content-Transfer-Encoding: 7bit Appendix D. Data Encoding Examples We give a few examples below but dont show the padding. ========== Example 1: ========== Structure with three fixed-lengthof, mandatory fields. struct S { uint16 a uint16 b uint16 c } (a) Describing all fields using SPARSEDATA Path-Data TLV Path to an instance of S ... SPARSEDATA TLV ElementIDof(a), lengthof(a), valueof(a) ElementIDof(b), lengthof(b), valueof(b) ElementIDof(c), lengthof(c), valueof(c) (b) Describing a subset of fields Path-Data TLV Path to an instance of S ... SPARSEDATA TLV ElementIDof(a), lengthof(a), valueof(a) ElementIDof(c), lengthof(c), valueof(c) Note: Even though we have non-optional elements in structure S, since we can uniquely identify elements, we can selectively send element of structure S (eg in the case of an update from CE to FE). (c) Describing all fields using a FULLDATA TLV Path-Data TLV Path to an instance of S ... FULLDATA TLV valueof(a) valueof(b) valueof(c) Doria (Ed.), et al. Expires February 2, 2006 [Page 82] Internet-Draft ForCES August 2005 ========== Example 2: ========== Structure with three fixed-lengthof fields, one mandatory, two optional. struct T { uint16 a uint16 b (optional) uint16 c (optional) } This example is identical to Example 1, as illustrated below. (a) Describing all fields using SPARSEDATA Path-Data TLV Path to an instance of S ... SPARSEDATA TLV ElementIDof(a), lengthof(a), valueof(a) ElementIDof(b), lengthof(b), valueof(b) ElementIDof(c), lengthof(c), valueof(c) (b) Describing a subset of fields using SPARSEDATA Path-Data TLV Path to an instance of S ... SPARSEDATA TLV ElementIDof(a), lengthof(a), valueof(a) ElementIDof(c), lengthof(c), valueof(c) (c) Describing all fields using a FULLDATA TLV Path-Data TLV Path to an instance of S ... FULLDATA TLV valueof(a) valueof(b) valueof(c) Note: FULLDATA TLV _cannot_ be used unless all fields are being described. ========== Example 3: ========== Doria (Ed.), et al. Expires February 2, 2006 [Page 83] Internet-Draft ForCES August 2005 Structure with a mix of fixed-lengthof and variable-lengthof fields, some mandatory, some optional (would be a good idea to show unions maybe). struct U { uint16 a string b (optional) uint16 c (optional) } (a) Describing all fields using SPARSEDATA Path to an instance of U ... SPARSEDATA TLV ElementIDof(a), lengthof(a), valueof(a) ElementIDof(b), lengthof(b), valueof(b) ElementIDof(c), lengthof(c), valueof(c) (b) Describing a subset of fields using SPARSEDATA Path to an instance of U ... SPARSEDATA TLV ElementIDof(a), lengthof(a), valueof(a) ElementIDof(c), lengthof(c), valueof(c) (c) Describing all fields using FULLDATA TLV Path to an instance of U ... Packed-Dataraw TLV FULLDATA TLV valueof(a) FULLDATA TLV valueof(b) valueof(c) Note: The variable-length field requires the addition of a FULLDATA TLV within the outer FULLDATA TLV as in the case of element b above. ========== Example 4: ========== Structure containing an array of another structure type. struct V { uint32 x uint32 y struct U z[] Doria (Ed.), et al. Expires February 2, 2006 [Page 84] Internet-Draft ForCES August 2005 } (a) Encoding using SPARSEDATA, with two instances of z[], also described with SPARSEDATA, assuming only the 10th and 15th subscript of z[] are encoded. path to instance of V ... SPARSEDATA TLV ElementIDof(x), lengthof(x), valueof(x) ElementIDof(y), lengthof(y), valueof(y) ElementIDof(z), lengthof(all below) ElementID = 10 (i.e index 10 from z[]), lengthof(all below) ElementIDof(a), lengthof(a), valueof(a) ElementIDof(b), lengthof(b), valueof(b) ElementID = 15 (index 15 from z[]), lengthof(all below) ElementIDof(a), lengthof(a), valueof(a) ElementIDof(c), lengthof(c), valueof(c) Note the holes in the elements of z (10 followed by 15). Also note the gap in index 15 with only elements a and c appearing but not b. Doria (Ed.), et al. Expires February 2, 2006 [Page 85] Internet-Draft ForCES August 2005 --=-/tV1cbbyZk7+7JA6gIQ3-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 13:27:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPkNn-00042D-Im for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 13:27:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06560 for ; Wed, 12 Oct 2005 13:27:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPkY5-0001Mx-Ha for forces-archive@IETF.ORG; Wed, 12 Oct 2005 13:37:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0110D15C@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 13:27:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87850624 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 13:27:10 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 13:27:09 -0400 Received: from [71.254.23.91] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12658681 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 11:26:38 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1129135971.7045.24.camel@localhost.localdomain> <1129136386.7045.27.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051012132304.0311ec10@localhost> Date: Wed, 12 Oct 2005 13:27:09 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: use cases appendix To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1129136386.7045.27.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 These look good. The cases described here reminded me of a case that we have not discussed, but which this syntax can represent. Suppose that a structure has an optional element b. And suppose that an instance has that element set. How does the CE cause that optional element to no longer occur? One way I can think of is to say that if a sparse data component has a length of zero (in a SET) then that is a request to remove that element. This has the drawback that there is no way to allow a zero length but present element in a SET request (i.e. to distinguish between a string that is to be undefined and a string that is to be set to length 0.) Another choices is to use the delete operation (which is currently defined for array elements. We should specify how it is handled. Yours, Joel At 12:59 PM 10/12/2005, Jamal Hadi Salim wrote: >Sorry, I posted the wrong text - that text also needs fixing (i forgot >about it);i dont have time today. Heres the correct text. > >cheers, >jamal > >On Wed, 2005-12-10 at 12:52 -0400, Jamal Hadi Salim wrote: > > Ok, attached is the appendix to match section 6.1. > > I need a pair of eyes or more to scan it for obvious errors. > > > > cheers, > > jamal > From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 14:02:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPkvt-0005G2-EL for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 14:02:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08311 for ; Wed, 12 Oct 2005 14:02:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPl6E-0002GX-P7 for forces-archive@IETF.ORG; Wed, 12 Oct 2005 14:13:12 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0110D195@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 14:02:27 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87853791 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 14:02:21 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 14:02:19 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9CHAVXK022559; Wed, 12 Oct 2005 10:10:31 -0700 (PDT) References: <1129135971.7045.24.camel@localhost.localdomain> <1129136386.7045.27.camel@localhost.localdomain> <6.2.1.2.0.20051012132304.0311ec10@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129140136.7045.40.camel@localhost.localdomain> Date: Wed, 12 Oct 2005 14:02:16 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: use cases appendix Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20051012132304.0311ec10@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On Wed, 2005-12-10 at 13:27 -0400, Joel M. Halpern wrote: > These look good. > The cases described here reminded me of a case that we have not discussed, > but which this syntax can represent. > Suppose that a structure has an optional element b. And suppose that an > instance has that element set. > How does the CE cause that optional element to no longer occur? > One way I can think of is to say that if a sparse data component has a > length of zero (in a SET) then that is a request to remove that > element. This has the drawback that there is no way to allow a zero length > but present element in a SET request (i.e. to distinguish between a string > that is to be undefined and a string that is to be set to length 0.) > Another choices is to use the delete operation (which is currently defined > for array elements. > The delete sounds simpler in my view. i.e instead of having an exception. On getting a deleted optionally appearing data, we should return a RESULT TLV with something along the lines of NOEXIST. Does that sound reasonable? Reminds me: Do we really think we have properly/sufficiently defined the result codes? > We should specify how it is handled. > Agreed. Suggestions on where to add such text? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 14:34:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPlRK-0006Te-HB for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 14:34:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09808 for ; Wed, 12 Oct 2005 14:34:54 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPlbf-000377-3p for forces-archive@IETF.ORG; Wed, 12 Oct 2005 14:45:41 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0110D186@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 14:34:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87855671 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 14:34:54 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 14:34:54 -0400 Received: from [71.254.23.91] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12658756; Wed, 12 Oct 2005 12:34:23 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1129135971.7045.24.camel@localhost.localdomain> <1129136386.7045.27.camel@localhost.localdomain> <6.2.1.2.0.20051012132304.0311ec10@localhost> <1129140136.7045.40.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051012143328.03125428@localhost> Date: Wed, 12 Oct 2005 14:34:53 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: use cases appendix Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1129140136.7045.40.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 In terms of where to add the text, if we go with the delete choice, then this section should include a note that SETting a variable length item to a 0 length value is not the same as deleteing it. And the section where the DELETE type code is defined should indicate that it can be used to delete an array element or an optional structure element. The syntax already allows for it, we should just call it out as permitted. Yours, Joel At 02:02 PM 10/12/2005, Jamal Hadi Salim wrote: >On Wed, 2005-12-10 at 13:27 -0400, Joel M. Halpern wrote: > > These look good. > > The cases described here reminded me of a case that we have not discussed, > > but which this syntax can represent. > > Suppose that a structure has an optional element b. And suppose that an > > instance has that element set. > > How does the CE cause that optional element to no longer occur? > > One way I can think of is to say that if a sparse data component has a > > length of zero (in a SET) then that is a request to remove that > > element. This has the drawback that there is no way to allow a zero > length > > but present element in a SET request (i.e. to distinguish between a string > > that is to be undefined and a string that is to be set to length 0.) > > Another choices is to use the delete operation (which is currently defined > > for array elements. > > > >The delete sounds simpler in my view. i.e instead of having an >exception. On getting a deleted optionally appearing data, we should >return a RESULT TLV with something along the lines of NOEXIST. >Does that sound reasonable? > >Reminds me: >Do we really think we have properly/sufficiently defined the result >codes? > > > We should specify how it is handled. > > > >Agreed. Suggestions on where to add such text? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 15:32:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmKw-0007Nq-BK for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 15:32:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13659 for ; Wed, 12 Oct 2005 15:32:23 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPmVI-0004w5-FQ for forces-archive@IETF.ORG; Wed, 12 Oct 2005 15:43:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0110D281@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 15:32:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87859999 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 15:31:21 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 15:30:58 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9CId8XK023497; Wed, 12 Oct 2005 11:39:08 -0700 (PDT) References: <1129135971.7045.24.camel@localhost.localdomain> <1129136386.7045.27.camel@localhost.localdomain> <6.2.1.2.0.20051012132304.0311ec10@localhost> <1129140136.7045.40.camel@localhost.localdomain> <6.2.1.2.0.20051012143328.03125428@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129145455.7045.45.camel@localhost.localdomain> Date: Wed, 12 Oct 2005 15:30:55 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: use cases appendix Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20051012143328.03125428@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On Wed, 2005-12-10 at 14:34 -0400, Joel M. Halpern wrote: > In terms of where to add the text, if we go with the delete choice, then Shall i assume this is what we are going with or do you feel strongly the other way? > this section should include a note that SETting a variable length item to a > 0 length value is not the same as deleteing it. And the section where the > DELETE type code is defined should indicate that it can be used to delete > an array element or an optional structure element. The syntax already > allows for it, we should just call it out as permitted. > I will add this text based on your response to above. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 15:40:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmSZ-0000h9-QW for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 15:40:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14026 for ; Wed, 12 Oct 2005 15:40:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPmcv-00059b-Pd for forces-archive@IETF.ORG; Wed, 12 Oct 2005 15:51:03 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0110D33D@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 15:40:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87860869 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 15:40:16 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 15:40:16 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9CImQXK023591; Wed, 12 Oct 2005 11:48:26 -0700 (PDT) References: <1129135971.7045.24.camel@localhost.localdomain> <1129136386.7045.27.camel@localhost.localdomain> <6.2.1.2.0.20051012132304.0311ec10@localhost> <1129140136.7045.40.camel@localhost.localdomain> <6.2.1.2.0.20051012143328.03125428@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129146013.7045.50.camel@localhost.localdomain> Date: Wed, 12 Oct 2005 15:40:13 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: use cases appendix Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20051012143328.03125428@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit On Wed, 2005-12-10 at 14:34 -0400, Joel M. Halpern wrote: > SETting a variable length item to a > 0 length value is not the same as deleteing it. Should we return an error code? What would it be? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 16:59:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPngq-00065y-34 for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 16:59:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05179 for ; Wed, 12 Oct 2005 16:59:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnrC-00053K-QU for forces-archive@IETF.ORG; Wed, 12 Oct 2005 17:09:52 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0110D5A1@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 16:59:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87870458 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 16:59:04 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 16:59:04 -0400 Received: from [71.254.23.91] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12659020; Wed, 12 Oct 2005 14:58:32 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1129135971.7045.24.camel@localhost.localdomain> <1129136386.7045.27.camel@localhost.localdomain> <6.2.1.2.0.20051012132304.0311ec10@localhost> <1129140136.7045.40.camel@localhost.localdomain> <6.2.1.2.0.20051012143328.03125428@localhost> <1129146013.7045.50.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051012165735.03129db8@localhost> Date: Wed, 12 Oct 2005 16:59:03 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: use cases appendix Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1129146013.7045.50.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 No need for an error code. it is a valid thing. Setting an array to have no entries. Setting a string to be the 0 length string. Setting a variable length bit string to have no bits. And all of those are different from removing the attribute. Now, some variable length items may have minimum lengths. Then such a set attempt should return an "invalid value" error. Yours, Joel At 03:40 PM 10/12/2005, Jamal Hadi Salim wrote: >On Wed, 2005-12-10 at 14:34 -0400, Joel M. Halpern wrote: > > SETting a variable length item to a > > 0 length value is not the same as deleteing it. > >Should we return an error code? What would it be? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 17:45:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPoQ7-0006kG-Np for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 17:45:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07467 for ; Wed, 12 Oct 2005 17:45:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPoaV-0006Eh-OS for forces-archive@IETF.ORG; Wed, 12 Oct 2005 17:56:40 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0110D639@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 17:45:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87873217 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 17:45:53 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 17:45:53 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9CLjqMk022250 for ; Wed, 12 Oct 2005 21:45:52 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9CLjp9S026540 for ; Wed, 12 Oct 2005 21:45:52 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101214384316268 for ; Wed, 12 Oct 2005 14:38:44 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 14:38:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5CF75.4BBA1971" X-MS-Has-Attach: yes Thread-Topic: updated text on HA section Thread-Index: AcXPdUt6WLMCFpNyRU6ADvYKl0rbbA== X-OriginalArrivalTime: 12 Oct 2005 21:38:31.0682 (UTC) FILETIME=[4A6EB620:01C5CF75] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E07029224@orsmsx408> Date: Wed, 12 Oct 2005 14:38:33 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: updated text on HA section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CF75.4BBA1971 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5CF75.4BBA1971" ------_=_NextPart_002_01C5CF75.4BBA1971 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text is attached as per the protocol team discussions. =20 regards Hormuzd =20 ------_=_NextPart_002_01C5CF75.4BBA1971 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The = text is attached=20 as per the protocol team discussions.
 
regards
Hormuzd
 
------_=_NextPart_002_01C5CF75.4BBA1971-- ------_=_NextPart_001_01C5CF75.4BBA1971 Content-Type: text/plain; name="ha-section.txt" Content-Transfer-Encoding: base64 Content-Description: ha-section.txt Content-Disposition: attachment; filename="ha-section.txt" Content-Transfer-Encoding: base64 OC4gSGlnaCBBdmFpbGFiaWxpdHkgU3VwcG9ydA0KDQpUaGUgRm9yQ0VTIHByb3RvY29sIHByb3Zp ZGVzIG1lY2hhbmlzbXMgZm9yIENFIHJlZHVuZGFuY3kgYW5kIGZhaWxvdmVyLCANCmluIG9yZGVy IHRvIHN1cHBvcnQgSGlnaCBBdmFpbGFiaWxpdHkgYXMgZGVmaW5lZCBpbiBbUkZDMzY1NF0uICBG RSByZWR1bmRhbmN5IA0KYW5kIEZFIHRvIEZFIGludGVyYWN0aW9uIGlzIGN1cnJlbnRseSBvdXQg b2Ygc2NvcGUgb2YgdGhpcyBkcmFmdC4gIFRoZXJlIA0KY2FuIGJlIG11bHRpcGxlIHJlZHVuZGFu dCBDRXMgYW5kIEZFcyBpbiBhIEZvckNFUyBORS4gIEhvd2V2ZXIsIGF0IGFueSANCnRpbWUgdGhl cmUgY2FuIG9ubHkgYmUgb25lIFByaW1hcnkgQ0UgY29udHJvbGxpbmcgdGhlIEZFcyBhbmQgdGhl cmUgY2FuIA0KYmUgbXVsdGlwbGUgc2Vjb25kYXJ5IENFcy4gIFRoZSBGRSBhbmQgdGhlIENFIFBM IGFyZSBhd2FyZSBvZiB0aGUgcHJpbWFyeSANCmFuZCBzZWNvbmRhcnkgQ0VzLiAgVGhpcyBpbmZv cm1hdGlvbiAocHJpbWFyeSwgc2Vjb25kYXJ5IENFcykgaXMgY29uZmlndXJlZCANCmluIHRoZSBG RSwgQ0UgUExzIGR1cmluZyBwcmUtYXNzb2NpYXRpb24gYnkgRkVNLCBDRU0gcmVzcGVjdGl2ZWx5 LiAgT25seSANCnRoZSBwcmltYXJ5IENFIHNlbmRzIENvbnRyb2wgbWVzc2FnZXMgdG8gdGhlIEZF cy4gDQoNClRoZXJlIGFyZSAyIG1vZGVzIG9mIEhBIGRlZmluZWQgaW4gdGhlIEZvckNFUyBwcm90 b2NvbCwgUmVwb3J0IFByaW1hcnkgTW9kZSANCmFuZCBSZXBvcnQgQWxsIE1vZGUuIFRoZSBSZXBv cnQgUHJpbWFyeSBNb2RlIGlzIHRoZSBkZWZhdWx0IG1vZGUgb2YgdGhlIHByb3RvY29sLCANCmlu IHdoaWNoIHRoZSBGRXMgb25seSBhc3NvY2lhdGUgd2l0aCBvbmUgQ0UgKHByaW1hcnkpIGF0IGEg dGltZS4gVGhlIFJlcG9ydCBBbGwgDQptb2RlIGlzIGZvciBmdXR1cmUgc3R1ZHkgYW5kIG5vdCBw YXJ0IG9mIHRoZSBjdXJyZW50IHByb3RvY29sIHZlcnNpb24uIEluIHRoaXMgbW9kZSwgDQp0aGUg RkUgd291bGQgZXN0YWJsaXNoIGFzc29jaWF0aW9uIHdpdGggbXVsdGlwbGUgQ0VzIChwcmltYXJ5 ICYgc2Vjb25kYXJ5KSBhbmQgDQpyZXBvcnQgZXZlbnRzLCBwYWNrZXRzLCBIZWFydCBCZWF0cyB0 byBhbGwgdGhlIENFcy4gSG93ZXZlciwgb25seSB0aGUgcHJpbWFyeSBDRSANCndvdWxkIGNvbmZp Z3VyZS9jb250cm9sIHRoZSBGRSBpbiB0aGlzIG1vZGUgYXMgd2VsbC4gVGhpcyBoZWxwcyB3aXRo IGtlZXBpbmcgc3RhdGUgDQpiZXR3ZWVuIENFcyBzeW5jaHJvbml6ZWQsIGFsdGhvdWdoIGl0IGRv ZXMgbm90IGd1YXJhbnRlZSBzeW5jaHJvbml6YXRpb24uIA0KDQpUaGUgSEEgTW9kZXMgYXJlIGNv bmZpZ3VyZWQgZHVyaW5nIEFzc29jaWF0aW9uIHNldHVwIHBoYXNlLCBjdXJyZW50bHkgb25seSBS ZXBvcnQgDQpQcmltYXJ5IE1vZGUgaXMgY29uZmlndXJlZC4gIEEgQ0UtdG8tQ0Ugc3luY2hyb25p emF0aW9uIHByb3RvY29sIHdpbGwgYmUgbmVlZGVkIA0KdG8gc3VwcG9ydCBmYXN0IGZhaWxvdmVy LCBob3dldmVyIHRoaXMgd2lsbCBub3QgYmUgZGVmaW5lZCBieSB0aGUgRm9yQ0VTIHByb3RvY29s Lg0KDQpEdXJpbmcgYSBjb21tdW5pY2F0aW9uIGZhaWx1cmUgYmV0d2VlbiB0aGUgRkUgYW5kIENF ICh3aGljaCBpcyBjYXVzZWQgZHVlIHRvIENFIA0Kb3IgbGluayByZWFzb25zLCBpLmUuIG5vdCBG RSByZWxhdGVkKSwgdGhlIFRNTCBvbiB0aGUgRkUgd2lsbCB0cmlnZ2VyIHRoZSBGRSBQTCANCnJl Z2FyZGluZyB0aGlzIGZhaWx1cmUuICBUaGlzIGNhbiBhbHNvIGJlIGRldGVjdGVkIHVzaW5nIHRo ZSBIQiBtZXNzYWdlcyBiZXR3ZWVuIA0KRkVzIGFuZCBDRXMuICBUaGUgY29tbXVuaWNhdGlvbiBm YWlsdXJlIChkZXRlY3RlZCB2aWEgZWl0aGVyIG9mIHRoZSB0d28gbWVhbnMgDQpkZXNjcmliZWQg YmVmb3JlKSBpcyBjb25zaWRlcmVkIGFzIGEgbG9zcyBvZiBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRo ZSBDRSBhbmQgDQpjb3JyZXNwb25kaW5nIEZFIGFuZCB0aGUgRkUgUEwgbXVzdCBlc3RhYmxpc2gg YXNzb2NpYXRpb24gd2l0aCB0aGUgc2Vjb25kYXJ5IENFIGF0IA0KdGhpcyBwb2ludC4gIER1cmlu ZyB0aGlzIHBoYXNlLCBpZiB0aGUgb3JpZ2luYWwgcHJpbWFyeSBDRSBjb21lcyBhbGl2ZSBhbmQg c3RhcnRzIA0Kc2VuZGluZyBhbnkgY29tbWFuZHMgdG8gdGhlIEZFLCB0aGUgRkUgc2hvdWxkIGln bm9yZSB0aG9zZSBtZXNzYWdlcyBhbmQgc2VuZCBhbiANCkV2ZW50IHRvIGFsbCBDRXMgaW5kaWNh dGluZyBpdHMgY2hhbmdlIGluIFByaW1hcnkgQ0UuICBUaHVzIHRoZSBGRSBvbmx5IGhhcyBvbmUg DQpwcmltYXJ5IENFIGF0IGEgdGltZS4NCg0KQW4gZXhwbGljaXQgbWVzc2FnZSAoQ29uZmlnIG1l c3NhZ2Ugc2V0dGluZyBQcmltYXJ5IENFIGF0dHJpYnV0ZSBpbiBGb3JDRVMgUHJvdG9jb2wgDQpv YmplY3QpIGZyb20gdGhlIHByaW1hcnkgQ0UsIGNhbiBhbHNvIGJlIHVzZWQgdG8gY2hhbmdlIHRo ZSBQcmltYXJ5IENFIGZvciBhbiBGRSANCmR1cmluZyBub3JtYWwgcHJvdG9jb2wgb3BlcmF0aW9u Lg0K ------_=_NextPart_001_01C5CF75.4BBA1971-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 18:17:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPouM-00005H-2a for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 18:17:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08825 for ; Wed, 12 Oct 2005 18:17:06 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPp4j-0006xv-97 for forces-archive@IETF.ORG; Wed, 12 Oct 2005 18:27:54 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0110D5F4@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 18:17:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87874999 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 18:17:06 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 18:17:06 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9CLPEXK024909; Wed, 12 Oct 2005 14:25:14 -0700 (PDT) References: <1129135971.7045.24.camel@localhost.localdomain> <1129136386.7045.27.camel@localhost.localdomain> <6.2.1.2.0.20051012132304.0311ec10@localhost> <1129140136.7045.40.camel@localhost.localdomain> <6.2.1.2.0.20051012143328.03125428@localhost> <1129146013.7045.50.camel@localhost.localdomain> <6.2.1.2.0.20051012165735.03129db8@localhost> Content-Type: multipart/mixed; boundary="=-1L16tY9eUQkghlPv9yYs" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129155423.6412.2.camel@localhost.localdomain> Date: Wed, 12 Oct 2005 18:17:03 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: use cases appendix Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20051012165735.03129db8@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd --=-1L16tY9eUQkghlPv9yYs Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, attached the diff incorporating all your other comments. Thanks for your efforts Joel. cheers, jamal On Wed, 2005-12-10 at 16:59 -0400, Joel M. Halpern wrote: > No need for an error code. it is a valid thing. Setting an array to have > no entries. Setting a string to be the 0 length string. Setting a > variable length bit string to have no bits. > And all of those are different from removing the attribute. > > Now, some variable length items may have minimum lengths. Then such a set > attempt should return an "invalid value" error. > > Yours, > Joel > > At 03:40 PM 10/12/2005, Jamal Hadi Salim wrote: > >On Wed, 2005-12-10 at 14:34 -0400, Joel M. Halpern wrote: > > > SETting a variable length item to a > > > 0 length value is not the same as deleteing it. > > > >Should we return an error code? What would it be? > > > >cheers, > >jamal > --=-1L16tY9eUQkghlPv9yYs Content-Disposition: attachment; filename=sec61-diff.txt Content-Type: text/plain; name=sec61-diff.txt; charset=utf-8 Content-Transfer-Encoding: 7bit --- sec-6.1.txt 2005-10-11 22:48:45.000000000 -0400 +++ sec-6.1-new.txt 2005-10-12 18:10:57.000000000 -0400 @@ -1,3 +1,4 @@ + 6. Protocol Construction 6.1. Protocol Grammar @@ -90,9 +91,10 @@ o PATH-DATA-TLV identifies the exact element targeted and may have zero or more paths associated with it. The last PATH-DATA-TLV in - the case of nesting of paths via the DATA construct is terminated - by encoded data or response in the form of either FULLDATA-TLV or - SPARSEDATA-TLV or RESULT-TLV. + the case of nesting of paths via the DATA construct in the case of + SET requests and GET response is terminated by encoded data or + response in the form of either FULLDATA-TLV or SPARSEDATA-TLV or + RESULT-TLV. o PATH provides the path to the data being referenced. @@ -207,13 +208,13 @@ transported. This data will be as was described in the LFB definition. - * As an example a 16 bit value within a TLV will have an extra - 16 bit pad; however two 16 bits values in another TLV - structure will be shipped together with no padding etc. - o Variable sized data within a FULLDATA TLV will be encapsulated inside another FULLDATA TLV inside the V of the outer TLV. For - example of this see Appendix E example 13. + example of such a setup refer to Appendix E and Appendix D. + + o In the case of FULLDATA TLVs: + + @@ -222,14 +223,12 @@ Internet-Draft ForCES August 2005 - o In the case of PACKEDDATA TLVs: - o When a table is refered to in the PATH (ids) of a PATH-DATA-TLV, - then the PACKEDDATA's "V" will contain that table's row content + then the FULLDATA's "V" will contain that table's row content prefixed by its 32 bit index/subscript. OTOH, when PATH flags are 00, the PATH may contain an index pointing to a row in table; in - such a case, the PACKEDDATA's "V" will only contain the content - with the index in order to avoid ambiguity. + such a case, the FULLDATA's "V" will only contain the content with + the index in order to avoid ambiguity. 6.1.1.1.2. Path Flags @@ -296,7 +297,7 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 11 + Figure 11: PL PDU layout Type: The type of the TLV is "LFBselect" @@ -325,7 +326,7 @@ of the TLV. Definitions for individual Types of operation TLVs are in corresponding message description sections followed. - + SET and GET Requests do not have result information (they are @@ -334,29 +335,6 @@ Internet-Draft ForCES August 2005 -6.1.1.1.7. Result TLV - - A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 - byte) value. - - The defined values are - - 0 = success - - 1 = no such object - - 2 = permission denied - - 3 = invalid value (the dataraw could not validly be stored in the - field) - - 4 = invalid array creation (when the subscript in an array create is - not allowed) - - 255 = unspecified error (for when the FE can not decide what went - wrong) - - SET and GET Requests do not have result information (they are requests). SET and GET Responses have result information. SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. @@ -365,11 +343,12 @@ elements that fail, instead of the FULLDATA TLV there will be a RESULT TLV. - For a SET response, each FULLDATA TLV in the original request will be - replace with a RESULT TLV in the response. If the request was for - Ack-fail, then only those items which failed will appear in the - response. If the request was for ack-all, then all elements of the - request will appear in the response with RESULT TLVs. + For a SET response, each FULLDATA or or SPARSEDATA TLV in the + original request will be replaced with a RESULT TLV in the response. + If the request was for Ack-fail, then only those items which failed + will appear in the response. If the request was for ack-all, then + all elements of the request will appear in the response with RESULT + TLVs. Note that if a SET request with a structure in a FULLDATA is issued, and some field in the structure is invalid, the FE will not attempt @@ -381,7 +360,29 @@ another field to an invalid value, the FE can return whatever error it likes. + A SET operation on a variable length element with a length of 0 for + the item is not the same as deleteing it. If the CE wishes to delete + then the DEL operation should be used whether the the path refers to + an array element or an optional structure element. +6.1.1.1.7. Result TLV + + A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 + byte) value. + + The defined values are + + 0 = success + + 1 = no such object + + 2 = permission denied + + 3 = invalid value (the dataraw could not validly be stored in the + field) + + 4 = invalid array creation (when the subscript in an array create is + not allowed) @@ -390,6 +391,9 @@ Internet-Draft ForCES August 2005 + 255 = unspecified error (for when the FE can not decide what went + wrong) + 6.1.1.1.8. DATA TLV A FULLDATA TLV has "T"= FULLDATA, and a 16bit Length followed by the @@ -398,8 +402,8 @@ the case of the SPARSEDATA each element in the Value part of the TLV will be further encapsulated in an ILV. Rules: - 1. Both ILVs and TLVs MUST 32 bit aligned. If need be they SHOULD - be padded to achieve the alignement. + 1. Both ILVs and TLVs MUST 32 bit aligned. If need be they MUST be + padded to achieve the alignement. 2. FULLDATA TLV may be used at a particular path only if every element at that path level is present. This requirement holds @@ -548,7 +549,7 @@ - Figure 12: PL PDU layout + Figure 12: PL PDU logical layout @@ -647,4 +648,3 @@ Figure 13: Sample operation layout - --=-1L16tY9eUQkghlPv9yYs-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 12 19:12:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPplQ-0001Km-FM for forces-archive@megatron.ietf.org; Wed, 12 Oct 2005 19:12:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11089 for ; Wed, 12 Oct 2005 19:11:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPpvo-00089P-LU for forces-archive@IETF.ORG; Wed, 12 Oct 2005 19:22:45 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0110D898@cherry.ease.lsoft.com>; Wed, 12 Oct 2005 19:11:58 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87871892 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Oct 2005 19:11:57 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 12 Oct 2005 19:11:56 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9CMK3XK025349 for ; Wed, 12 Oct 2005 15:20:04 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-UmUVf1EDUvYZucfl8c4G" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129158713.6412.12.camel@localhost.localdomain> Date: Wed, 12 Oct 2005 19:11:53 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: real use cases appendix text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.3 (/) X-Scan-Signature: c5360d8dc5896b7620777c236feb980a --=-UmUVf1EDUvYZucfl8c4G Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, I fixed the text i mistakenly posted earlier. Please comment. cheers, jamal --=-UmUVf1EDUvYZucfl8c4G Content-Disposition: attachment; filename=use-cases.txt Content-Type: text/plain; name=use-cases.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Appendix E. Use Cases Assume LFB with following attributes for the following use cases. foo1, type u32, ID = 1 foo2, type u32, ID = 2 table1: type array, ID = 3 elements are: t1, type u32, ID = 1 t2, type u32, ID = 2 // index into table 2 KEY: nhkey, ID = 1, V = t2 table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 KEY: akey, ID = 1, V = { j1,j2 } table3: type array, ID = 5 elements are: someid, type u32, ID = 1 name, type string variable sized, ID = 2 table4: type array, ID = 6 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 j3, type u32, ID = 3 j4, type u32, ID = 4 KEY: mykey, ID = 1, V = { j1} table5: type array, ID = 7 elements are: p1, type u32, ID = 1 p2, type array, ID = 2, array elements of type-X Type-X: x1, ID 1, type u32 x2, ID2 , type u32 KEY: tkey, ID = 1, V = { x1} All examples will show an attribute suffixed with "v" or "val" to Doria (Ed.), et al. Expires February 2, 2006 [Page 86] Internet-Draft ForCES August 2005 indicate the value of the referenced attribute. example for attribute foo2, foo1v or foo1value will indicate the value of foo1. In the case where F_SEL** are missing (bits equal to 00) then the flags will not show any selection. All the examples only show use of FULLDATA for data encoding; although SPARSEDATA would make more sense in certain occassions, the emphasis is on showing the message layout. Refer to Appendix D for examples that show usage of both FULLDATA and SPARSEDATA. 1. To get foo1 OPER = GET-TLV Path-data TLV: IDCount = 1, IDs = 1 Result: OPER = GET-RESPONSE-TLV Path-data-TLV: flags=0, IDCount = 1, IDs = 1 FULLDATA-TLV L = 4+4, V = foo1v 2. To set foo2 to 10 OPER = SET-REPLACE-TLV Path-data-TLV: flags = 0, IDCount = 1, IDs = 2 FULLDATA TLV: L = 4+4, V=10 Result: OPER = SET-RESPONSE-TLV Path-data-TLV: flags = 0, IDCount = 1, IDs = 2 RESULT-TLV 3. To dump table2 OPER = GET-TLV Path-data-TLV: IDCount = 1, IDs = 4 Result: OPER = GET-RESPONSE-TLV Path-data-TLV: flags = 0, IDCount = 1, IDs = 4 FULLDATA=TLV: L = XXX, V= a series of: index, j1value,j2value entries representing the entire table Doria (Ed.), et al. Expires February 2, 2006 [Page 87] Internet-Draft ForCES August 2005 4. Note: One should be able to take a GET-RESPONSE-TLV and convert it to a SET-REPLACE-TLV. If the result in the above example is sent back in a SET-REPLACE-TLV, (instead of a GET-RESPONSE_TLV) then the entire contents of the table will be replaced at that point. 5. Multiple operations Example. To create entry 0-5 of table2 (Ignore error conditions for now) Doria (Ed.), et al. Expires February 2, 2006 [Page 88] Internet-Draft ForCES August 2005 OPER = SET-CREATE-TLV Path-data-TLV: flags = 0 , IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 FULLDATA-TLV containing j1, j2 value for entry 0 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 1 FULLDATA-TLV containing j1, j2 value for entry 1 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 FULLDATA-TLV containing j1, j2 value for entry 2 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 FULLDATA-TLV containing j1, j2 value for entry 3 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 4 FULLDATA-TLV containing j1, j2 value for entry 4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 5 FULLDATA-TLV containing j1, j2 value for entry 5 Result: OPER = SET-RESPONSE-TLV Path-data-TLV: flags = 0 , IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 4 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 5 RESULT-TLV Doria (Ed.), et al. Expires February 2, 2006 [Page 89] Internet-Draft ForCES August 2005 6. Block operations (with holes) example. Replace entry 0,2 of table2 OPER = SET-REPLACE-TLV Path-data TLV: flags = 0 , IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 FULLDATA-TLV containing j1, j2 value for entry 0 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 FULLDATA-TLV containing j1, j2 value for entry 2 Result: OPER = SET-REPLACE-TLV Path-data TLV: flags = 0 , IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 RESULT-TLV PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV 7. Getting rows example. Get first entry of table2. OPER = GET-TLV Path-data TLV: IDCount = 2, IDs=4.0 Result: OPER = GET-RESPONSE-TLV Path-data TLV: IDCount = 2, IDs=4.0 FULLDATA TLV, Length = XXX, V = j1value,j2value entry 8. Get entry 0-5 of table2. Doria (Ed.), et al. Expires February 2, 2006 [Page 90] Internet-Draft ForCES August 2005 OPER = GET-TLV Path-data-TLV: flags = 0, IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 1 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 5 Result: OPER = GET-RESPONSE-TLV Path-data-TLV: flags = 0, IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 FULLDATA-TLV containing j1value j2value PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 1 FULLDATA-TLV containing j1value j2value PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 FULLDATA-TLV containing j1value j2value PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 FULLDATA-TLV containing j1value j2value PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 4 FULLDATA-TLV containing j1value j2value PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 5 FULLDATA-TLV containing j1value j2value 9. Create a row in table2, index 5. Doria (Ed.), et al. Expires February 2, 2006 [Page 91] Internet-Draft ForCES August 2005 OPER = SET-CREATE-TLV Path-data-TLV: flags = 0, IDCount = 2, IDs=4.5 FULLDATA TLV, Length = XXX j1value,j2value Result: OPER = SET-RESPONSE-TLV Path-data TLV: flags = 0, IDCount = 1, IDs=4.5 RESULT-TLV 10. An example of "create and give me an index" Assuming we asked for verbose response back in the main message header. OPER = SET-CREATE-TLV Path-data -TLV: flags = FIND-EMPTY, IDCount = 1, IDs=4 FULLDATA TLV, Length = XXX j1value,j2value Result If 7 were the first unused entry in the table: OPER = SET-RESPONSE Path-data TLV: flags = 0, IDCount = 2, IDs=4.7 RESULT-TLV indicating success, and FULLDATA-TLV, Length = XXX j1value,j2value 11. Dump contents of table1. OPER = GET-TLV Path-data TLV: flags = 0, IDCount = 1, IDs=3 Result: OPER = GET-RESPONSE-TLV Path-data TLV flags = 0, IDCount = 1, IDs=3 FULLDATA TLV, Length = XXXX (depending on size of table1) index, t1value, t2value index, t1value, t2value . Doria (Ed.), et al. Expires February 2, 2006 [Page 92] Internet-Draft ForCES August 2005 . . 12. Using Keys. Get row entry from table4 where j1=100. Recall, j1 is a defined key for this table and its keyid is 1. OPER = GET-TLV Path-data-TLV: flags = F_SELKEY IDCount = 1, IDs=6 KEYINFO-TLV = KEYID=1, KEY_DATA=100 Result: If j1=100 was at index 10 OPER = GET-RESPONSE-TLV Path-data TLV: flags = 0, IDCount = 1, IDs=6.10 FULLDATA TLV, Length = XXXX j1value,j2value, j3value, j4value 13. Delete row with KEY match (j1=100, j2=200) in table 2. Note that the j1,j2 pair are a defined key for the table 2. OPER = DEL-TLV Path-data TLV: flags = F_SELKEY IDCount = 1, IDs=4 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} Result: If (j1=100, j2=200) was at entry 15: OPER = DELETE-RESPONSE-TLV Path-data TLV: flags = 0 IDCount = 2, IDs=4.15 RESULT-TLV (with FULLDATA if verbose) 14. Dump contents of table3. It should be noted that this table has a column with element name that is variable sized. The purpose of this use case is to show how such an element is to be encoded. Doria (Ed.), et al. Expires February 2, 2006 [Page 93] Internet-Draft ForCES August 2005 OPER = GET-TLV Path-data-TLV: flags = 0 IDCount = 1, IDs=5 Result: OPER = GET-RESPONSE-TLV Path-data TLV: flags = 0 IDCount = 1, IDs=5 FULLDATA TLV, Length = XXXX index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), V = namev . . . 15. Multiple atomic operations. 16. Note: This emulates adding a new nexthop entry and then atomically updating the L3 entries pointing to an old NH to point to a new one. The assumption is both tables are in the same LFB 17. Main header has atomic flag set and we are request for verbose/ full results back; Two operations on the LFB instance, both are SET operations. Doria (Ed.), et al. Expires February 2, 2006 [Page 94] Internet-Draft ForCES August 2005 //Operation 1: Add a new entry to table2 index #20. OPER = SET-CREATE-TLV Path-TLV: flags = 0, IDCount = 2, IDs=4.20 FULLDATA TLV, V= j1value,j2value // Operation 2: Update table1 entry which // was pointing with t2 = 10 to now point to 20 OPER = SET-REPLACE-TLV Path-data-TLV: flags = F_SELKEY, IDCount = 1, IDs=3 KEYINFO = KEYID=1 KEY_DATA=10 Path-data-TLV flags = 0 IDCount = 1, IDs=2 FULLDATA TLV, V= 20 Result: //first operation, SET OPER = SET-RESPONSE-TLV Path-data-TLV flags = 0 IDCount = 3, IDs=4.20 RESULT-TLV code = success FULLDATA TLV, V = j1value,j2value // second opertion SET - assuming entry 16 was updated OPER = SET-RESPONSE-TLV Path-data TLV flags = 0 IDCount = 2, IDs=3.16 Path-Data TLV flags = 0 IDCount = 1, IDs = 2 SET-RESULT-TLV code = success FULLDATA TLV, Length = XXXX v=20 // second opertion SET OPER = SET-RESPONSE-TLV Path-data TLV flags = 0 IDCount = 1, IDs=3 KEYINFO = KEYID=1 KEY_DATA=10 Path-Data TLV flags = 0 IDCount = 1, IDs = 2 SET-RESULT-TLV code = success FULLDATA TLV, Length = XXXX v=20 18. Selective setting (Example posted by Weiming). On table 4 -- for indices 1, 3, 5, 7, and 9. Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. PER = SET-REPLACE-TLV Doria (Ed.), et al. Expires February 2, 2006 [Page 95] Internet-Draft ForCES August 2005 Path-data TLV flags = 0, IDCount = 1, IDs = 6 Path-data TLV flags = 0, IDCount = 1, IDs = 1 Path-data TLV flags = 0, IDCount = 1, IDs = 1 FULLDATA TLV, Length = XXXX, V = {100} Path-data TLV flags = 0, IDCount = 1, IDs = 2 FULLDATA TLV, Length = XXXX, V = {200} Path-data TLV flags = 0, IDCount = 1, IDs = 3 FULLDATA TLV, Length = XXXX, V = {300} Path-data TLV flags = 0, IDCount = 1, IDs = 3 Path-data TLV flags = 0, IDCount = 1, IDs = 1 FULLDATA TLV, Length = XXXX, V = {100} Path-data TLV flags = 0, IDCount = 1, IDs = 2 FULLDATA TLV, Length = XXXX, V = {200} Path-data TLV flags = 0, IDCount = 1, IDs = 3 FULLDATA TLV, Length = XXXX, V = {300} Path-data TLV flags = 0, IDCount = 1, IDs = 5 Path-data TLV flags = 0, IDCount = 1, IDs = 1 FULLDATA TLV, Length = XXXX, V = {100} Path-data TLV flags = 0, IDCount = 1, IDs = 2 FULLDATA TLV, Length = XXXX, V = {200} Path-data TLV flags = 0, IDCount = 1, IDs = 3 FULLDATA TLV, Length = XXXX, V = {300} Path-data TLV flags = 0, IDCount = 1, IDs = 7 Path-data TLV flags = 0, IDCount = 1, IDs = 1 FULLDATA TLV, Length = XXXX, V = {100} Path-data TLV flags = 0, IDCount = 1, IDs = 2 FULLDATA TLV, Length = XXXX, V = {200} Path-data TLV flags = 0, IDCount = 1, IDs = 3 FULLDATA TLV, Length = XXXX, V = {300} Path-data TLV flags = 0, IDCount = 1, IDs = 9 Doria (Ed.), et al. Expires February 2, 2006 [Page 96] Internet-Draft ForCES August 2005 Path-data TLV flags = 0, IDCount = 1, IDs = 1 FULLDATA TLV, Length = XXXX, V = {100} Path-data TLV flags = 0, IDCount = 1, IDs = 2 FULLDATA TLV, Length = XXXX, V = {200} Path-data TLV flags = 0, IDCount = 1, IDs = 3 FULLDATA TLV, Length = XXXX, V = {300} Non-verbose response mode shown: OPER = SET-RESPONSE-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 6 Path-data TLV flags = 0, IDCount = 1, IDs = 1 Path-data TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 Path-data TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 5 Path-data TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 Doria (Ed.), et al. Expires February 2, 2006 [Page 97] Internet-Draft ForCES August 2005 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 7 Path-data TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 9 Path-data TLV flags = 0, IDCount = 1, IDs = 1 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 2 RESULT-TLV Path-data TLV flags = 0, IDCount = 1, IDs = 3 RESULT-TLV 19. Manipulation of table of table examples. Get x1 from table10 row with index 4, inside table5 entry 10 operation = GET-TLV Path-data-TLV flags = 0 IDCount = 5, IDs=7.10.2.4.1 Results: operation = GET-RESPONSE-TLV Path-data-TLV flags = 0 IDCount = 5, IDs=7.10.2.4.1 FULLDATA TLV: L=XXXX, V = {x1 value} 20. From table5's row 10 table10, get X2s based on on the value of x1 equlaing 10 (recal x1 is KeyID 1) Doria (Ed.), et al. Expires February 2, 2006 [Page 98] Internet-Draft ForCES August 2005 operation = GET-TLV Path-data-TLV flag = F_SELKEY, IDCount=3, IDS = 7.10.2 KEYINFO TLV, KEYID = 1, KEYDATA = 10 Path-data TLV IDCount = 1, IDS = 2 //select x2 Results: If x1=10 was at entry 11: operation = GET-RESPONSE-TLV Path-data-TLV flag = 0, IDCount=5, IDS = 7.10.2.11 Path-data TLV flags = 0 IDCount = 1, IDS = 2 FULLDATA TLV: L=XXXX, V = {x2 value} 21. Further example of table of table Consider table 6 which is defined as: table6: type array, ID = 8 elements are: p1, type u32, ID = 1 p2, type array, ID = 2, array elements of type type-A type-A: a1, type u32, ID 1, a2, type array ID2 ,array elements of type type-B type-B: b1, type u32, ID 1 b2, type u32, ID 2 So lets say we wanted to set by replacing: table6.10.p1 to 111 table6.10.p2.20.a1 to 222 table6.10.p2.20.a2.30.b1 to 333 in one message and one operation. There are two ways to do this: a) using nesting operation = SET-REPLACE-TLV Path-data-TLV flags = 0 IDCount = 2, IDs=6.10 Path-data-TLV Doria (Ed.), et al. Expires February 2, 2006 [Page 99] Internet-Draft ForCES August 2005 flags = 0, IDCount = 1, IDs=1 FULLDATA TLV: L=XXXX, V = {111} Path-data-TLV flags = 0 IDCount = 2, IDs=2.20 Path-data-TLV flags = 0, IDCount = 1, IDs=1 FULLDATA TLV: L=XXXX, V = {222} Path-data TLV : flags = 0, IDCount = 3, IDs=2.30.1 FULLDATA TLV: L=XXXX, V = {333} Result: operation = SET-RESPONSE-TLV Path-data-TLV flags = 0 IDCount = 2, IDs=6.10 Path-data-TLV flags = 0, IDCount = 1, IDs=1 RESULT-TLV Path-data-TLV flags = 0 IDCount = 2, IDs=2.20 Path-data-TLV flags = 0, IDCount = 1, IDs=1 RESULT-TLV Path-data TLV : flags = 0, IDCount = 3, IDs=2.30.1 RESULT-TLV b) using a flat path data operation = SET-REPLACE-TLV Path-data TLV : flags = 0, IDCount = 3, IDs=6.10.1 FULLDATA TLV: L=XXXX, V = {111} Path-data TLV : flags = 0, IDCount = 5, IDs=6.10.1.20.1 FULLDATA TLV: L=XXXX, V = {222} Path-data TLV : flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 FULLDATA TLV: L=XXXX, V = {333} Result: operation = SET-REPLACE-TLV Path-data TLV : flags = 0, IDCount = 3, IDs=6.10.1 RESULT-TLV Path-data TLV : Doria (Ed.), et al. Expires February 2, 2006 [Page 100] Internet-Draft ForCES August 2005 flags = 0, IDCount = 5, IDs=6.10.1.20.1 RESULT-TLV Path-data TLV : flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 RESULT-TLV 22. Get a whole LFB (all its attributes etc). 23. For example, at startup a CE might well want the entire FE OBJECT LFB. So, in a request targetted at class 1, instance 1, one might find: operation = GET-TLV Path-data-TLV flags = 0 IDCount = 0 result: operation = GET-RESPONSE-TLV Path-data-TLV flags = 0 IDCount = 0 FULLDATA encoding of the FE Object LFB Doria (Ed.), et al. Expires February 2, 2006 [Page 101] --=-UmUVf1EDUvYZucfl8c4G-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 04:03:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPy3r-0004uY-Mt for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 04:03:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01233 for ; Thu, 13 Oct 2005 04:03:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPyEJ-00030X-Le for forces-archive@IETF.ORG; Thu, 13 Oct 2005 04:14:25 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0110DE71@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 4:03:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87898414 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 04:03:29 -0400 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 04:03:29 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOA00KKVH2R0E@szxga03-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 16:04:04 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOA00L40H2PAO@szxga03-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 16:04:03 +0800 (CST) Received: from lenovo111 ([10.110.100.34]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOA00EARH9HLN@szxml02-in.huawei.com>; Thu, 13 Oct 2005 16:08:05 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <434BB83B.5050100@zurich.ibm.com> Approved-By: Guo xiaoyi Message-ID: <03f601c5cfcc$311fc1d0$22646e0a@china.huawei.com> Date: Thu, 13 Oct 2005 16:00:35 +0800 Reply-To: Guo xiaoyi Sender: Forwarding and Control Element Separation From: Guo xiaoyi Organization: Huawei.com Subject: Re: ForCES MIB: 1st draft Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.2 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: base64 aGksIFJvYmVydCwNCg0KaSBhbSBhIG5ld2VyIGNvbWUgaW4gdGhpcyBncm91cCBhbmQgd2lzaCBp IHdvbnQgZ2l2ZSBhIGJhZCBjb21tZW50ICA7KQ0KDQppIGhhdmUgbm90IHNlZW4gdGhlIGRyYWZ0 IHlldCwgYnV0IGkgd2FudCB0byBleHByZXNzIHNvbWUgc3VnZ2VzdGlvbnMuDQoNClRoZXJlIGFy ZSB0d28gd2F5IHRvIGdldCB0aGUgTUlCIGluZm9ybWF0aW9uICwgb25lIHdheSBpcyBlYWNoIHRp bWUgQ0UgcXVlcnkgRkUocykgYW5kIEZFKHMpIHJldHVybiB0aGUgDQpuZWNjZXNhcnkgaW5mb3Jt YWl0b24gdG8gQ0UuIEFub3RoZXIgd2F5IGlzIEZFKHMpIHNlbmQgdGhlIGluZm9ybWF0aW9uIHRv IENFICB3aXRoaW4gYSB0aW1lIGludGVydmFsLiANCg0KSWYgd2UgdXNlIHRoZSBmaXJzdCBtZXRo b2QgLCB0aGVuIHdlIGNvdWxkIGdldCB0aGUgcmVhbC10aW1lIGluZm9ybWF0aW9uIG9mIEZFKHMp ICwgYnV0IHdlIGNob3VsZCBub3QgDQpkZWNpZGUgd2hpY2ggb2xkIGFzc29jaWF0aW9ucyB0byBy ZW1vdmUgZnJvbSB0aGUgTUlCIGluIHRpbWUuIElmIHdlIHVzZSB0aGUgbGF0dGVyIG9uZSAsIHdl IGNhbiBkZWNpZGUgaXQgYnV0IHdlDQptYXliZSBjYW4gbm90ICBnZXQgcmVhbC10aW1lIGluZm9y bWF0aW9uICwgaXRzIGp1c3QgdGhlIG9sZCBpbmZvcm1haXRvbiBvZiB0aGUgbGFzdCB0aW1lIGlu dGVydmFsLg0KDQpjaGVlcnMNClhpYW95aSBHdW8NCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQpGcm9tOiAiIFJvYmVydCBIYWFzIDxyaGFAenVyaWNoLmlibS5jb20+DQpTdWJq ZWN0OiBGb3JDRVMgTUlCOiAxc3QgZHJhZnQNCg0KPiBBbGwsDQo+IEknbSBjdXJyZW50bHkgcHV0 dGluZyB0b2dldGhlciBhIGZpcnN0IGRyYWZ0IG9mIHRoZSBGb3JDRVMgTUlCIChhIA0KPiByZXF1 aXJlbWVudCB0byBwcm9jZWVkIHdpdGggb3VyIHByb3RvY29sIGRyYWZ0KSwgYW5kIHdpbGwgc3Vi bWl0IA0KPiBpdCBpdCANCj4gYnkgTW9uZGF5Lg0KPiBCZWxvdyBhcmUgdGhlIG1ham9yIHBvaW50 cywgcGxlYXNlIGNvbW1lbnQuDQo+IA0KPiBUaGUgRm9yQ0VTIE1JQiBpcyBhIHJlYWQtb25seSBN SUIgdXNlZCB0byBtb25pdG9yIHRoZSBzdGF0ZSBvZiANCj4gYXNzb2NpYXRpb25zIGluIGFuIE5F LiBGb3IgZWFjaCBhc3NvY2lhdGlvbiBpZGVudGlmaWVkIGJ5IHRoZSBwYWlyIA0KPiBDRSBJRCAN Cj4gYW5kIEZFIElELCB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIGlzIHNob3duOg0KPiANCj4g LSBDdXJyZW50IHN0YXRlIG9mIHRoZSBhc3NvY2lhdGlvbjoNCj4gDQo+ICAgVVA6ICAgICAgICAg ICB0aGUgQ0UocykgaW5kaWNhdGVkIGJ5IHRoZSBDRSBJRCBhbmQgRkUocykgDQo+IGluZGljYXRl ZCBieSANCj4gdGhlIEZFIElEIGFyZSBhc3NvY2lhdGVkLg0KPiAgIERPV046ICAgdGhlIENFKHMp IGluZGljYXRlZCBieSB0aGUgQ0UgSUQgYW5kIEZFKHMpIGluZGljYXRlZCBieSANCj4gdGhlIA0K PiBGRSBJRCBhcmUgbm90IGFzc29jaWF0ZWQgQU5EIHRoZSBDRShzKSBpbmRpY2F0ZWQgYnkgdGhl IENFIElEIGlzIA0KPiBzZW5kaW5nIA0KPiBBc3NvY2lhdGlvbiBTZXR1cCBtZXNzYWdlcy4NCj4g Tm90ZSB0aGF0IGFzc29jaWF0aW9ucyB0aGF0IGFyZSBET1dOIGFuZCBmb3Igd2hpY2ggbm8gQXNz b2NpYXRpb24gDQo+IFNldHVwIA0KPiBtZXNzYWdlcyBhcmUgYmVpbmcgc2VudCBieSB0aGUgQ0Ug YXJlIE5PVCBsaXN0ZWQgaW4gdGhlIE1JQiANCj4gKG90aGVyd2lzZSANCj4gaG93IGRvIHdlIGRl Y2lkZSB3aGljaCBvbGQgYXNzb2NpYXRpb25zIHRvIHJlbW92ZSBmcm9tIHRoZSBNSUIgPykNCj4g DQo+IC0gQXNzb2NpYXRpb24gaGlzdG9yeToNCj4gICBEYXRlL3RpbWUgd2hlbiB0aGUgYXNzb2Np YXRpb24gY2FtZSB0byB0aGUgVVAgc3RhdGUuDQo+ICAgKE51bWJlciBvZiBjb21tYW5kcyBleGVj dXRlZCBvciBzb21lIGluZGljYXRpb25zIG9mIHRoZSBGb3JDRVMgDQo+IGNvbnRyb2wgdHJhZmZp YyA/KQ0KPiANCj4gLSBIZWFyYmVhdCB0aW1lcnMgdmFsdWVzIG9mIHRoZSBGRSBhbmQgQ0UgZm9y IHRoaXMgYXNzb2NpYXRpb24uDQo+IA0KPiAtIEhlYXJ0YmVhdCB0aW1lciBzZXR0aW5ncyBvZiB0 aGUgRkUgYW5kIENFIGZvciB0aGlzIGFzc29jaWF0aW9uOiANCj4gDQo+ICAgRU5BQkxFRDogIGhl YXJiZWF0cyBhcmUgdHJhbnNtaXR0ZWQgKGJ5IGRlZmF1bHQgdmlydHVhbCANCj4gcGlnZ3liYWNr aW5nIA0KPiBpcyB1c2VkKQ0KPiAgIERJU0FCTEVEOiBoZWFydGJlYXRzIGFyZSBub3QgdHJhbnNt aXR0ZWQNCj4gDQo+IC0gQmFja3VwIGluZm9ybWF0aW9uOiB0aGUgRkUocykvQ0UocykgdGhhdCBh cmUgY29uZmlndXJlZCB0byB3b3JrIA0KPiBhcyANCj4gYmFja3VwcyBmb3IgdGhpcyBhc3NvY2lh dGlvbiAobmVjZXNzYXJ5ID8gdXNlZnVsID8pDQo+IA0KPiANCj4gDQo+IFJlZ2FyZHMsDQo+IA0K PiAtLSANCj4gRHIuIFJvYmVydCBSLiBIYWFzDQo+IElCTSBadXJpY2ggUmVzZWFyY2ggTGFib3Jh dG9yeQ0KPiBTP3VtZXJzdHJhc3NlIDQNCj4gQ0gtODgwMyBS/HNjaGxpa29uL1N3aXR6ZXJsYW5k DQo+IHBob25lICs0MS00NC03MjQtODY5OCAgZmF4ICs0MS00NC03MjQtODU3OCAgDQo+IGh0dHA6 Ly93d3cuenVyaWNoLmlibS5jb20vfnJoYQ== From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 05:21:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPzHG-0000hu-Ms for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 05:21:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05025 for ; Thu, 13 Oct 2005 05:21:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPzRb-0005BX-88 for forces-archive@IETF.ORG; Thu, 13 Oct 2005 05:32:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0110DF7E@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 5:21:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87909280 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 05:21:18 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 05:21:14 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 13 Oct 2005 18:01:19 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Thu, 13 Oct 2005 17:20:09 +0800 References: <1129131446.7045.12.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <00f801c5cfd7$27b615d0$1152010a@Necom.hzic.edu.cn> Date: Thu, 13 Oct 2005 17:19:03 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: HA section effect on overview To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Jamal, I lost track of the most current draft version. Could you post it? Thanks, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Wednesday, October 12, 2005 11:37 PM Subject: HA section effect on overview > > I have made the change outlined in the diff based on the new agreed mods > to HA. Please comment/nod/hum/whistle. > > Weiming, If you have time send me text on the HB message and agreed to > text with the HA mods. Otherwise i will get to it in the near future. > Sorry, I was busy and didnt follow the discussion to completion. > > cheers, > jamal > From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 05:54:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPznL-0000vB-J3 for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 05:54:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06341 for ; Thu, 13 Oct 2005 05:54:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPzxq-0005zr-5a for forces-archive@IETF.ORG; Thu, 13 Oct 2005 06:05:30 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0110DF9F@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 5:54:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87910398 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 05:54:37 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 05:54:35 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 13 Oct 2005 18:34:59 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Thu, 13 Oct 2005 17:53:49 +0800 References: <1129133707.7045.19.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <012201c5cfdb$dbfebf20$1152010a@Necom.hzic.edu.cn> Date: Thu, 13 Oct 2005 17:52:44 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: section 6.1 grammar update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Jamal, I appreciate the update. A suggestion of the text as below. The BNF of the PL level PDU is as follows: PL level PDU := MAINHDR [MAIN-TLV] MAIN-TLV := [LFBselect-TLV] / [REDIRECT-TLV] / [ASResult-TLV] / [ASTreason-TLV] LFBselect-TLV := LFBCLASSID LFBInstance OPER-TLV ....... The BNF of the PL level PDU is as follows: PL level PDU := MAINHDR [MAIN-TLV] MAIN-TLV := [LFBselect-TLV] / [Redirect-TLV] / !-- note the change of lowercase of Redirect for the consistency [ASRresult-TLV] / [ASTreason-TLV] !-- note the change of ASRresult Where, Redirect-TLV is only applied to the Packet Redirect Message, and the definition of the TLV can be found in Section 6.8; ASRresult-TLV is only applied to Association Setup Response Message, and the definition of the TLV can be found in Section 6.4.2; ASTreason-TLV is only applied to Association Teardown Message, and the definition of the TLV can be found in Section 6.4.3. LFBselect-TLV is a common TLV that are applied to Configurtion Messages, Query Messages, and Association Setup Message. The BNF grammar is shown as below. LFBselect-TLV := LFBCLASSID LFBInstance OPER-TLV ....... Jamal, please just decide if the above text is necessary or not under your consideration. Thanks, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Thursday, October 13, 2005 12:15 AM Subject: section 6.1 grammar update > > Folks, > Please review this closely. Joel - if you can pay close attention to > this I would appreciate it. There has been some major updates to sync > with other sections etc. > > I will follow up with the use cases appendix to reflect accurately the > details shown. > > All the text in the rest of section 6 needs to be synchronized with this > section. Its more of mechanical time consuming work i.e nothing to > discuss really. I wont have time to touch that today. > > cheers, > jamal > From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 06:02:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPzuu-0002vN-VM for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 06:02:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06746 for ; Thu, 13 Oct 2005 06:02:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ05O-0006Ax-7r for forces-archive@IETF.ORG; Thu, 13 Oct 2005 06:13:19 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0110DF59@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 6:02:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87911851 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 06:02:19 -0400 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 06:00:59 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOA00DRBMJDBX@szxga03-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 18:02:01 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOA00EBKMJC7B@szxga03-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 18:02:01 +0800 (CST) Received: from lenovo111 ([10.110.100.34]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOA005EXMVKQJ@szxml01-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 18:09:21 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/alternative; boundary="Boundary_(ID_la4wFKpEYU+YHmjJANgChw)" X-Priority: 3 X-MSMail-priority: Normal Approved-By: Xiaoyi Guo Message-ID: <044f01c5cfdc$ab642930$22646e0a@china.huawei.com> Date: Thu, 13 Oct 2005 17:58:31 +0800 Reply-To: Xiaoyi Guo Sender: Forwarding and Control Element Separation From: Xiaoyi Guo Organization: Huawei Tech. Subject: ForCES Intra-NE routing mechanism To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.5 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 This is a multi-part message in MIME format. --Boundary_(ID_la4wFKpEYU+YHmjJANgChw) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT All, I'm currently putting a draft of the ForCES Intra-NE routing mechaniam, and will submit it by Thusday.Below are the major points, please comment. About ForCES Intra-NE routing mechanism ----------------- | CE | ----------------- A ^ B ^ C ^ / | \ / A v \ / ------- B \ / +->| FE3 |<-+ \ / |C | | | \ A v | ------- | v A -------B | |E ------- | FE1 |<-+ +->| FE2 | | |<--------------->| | ------- C D ------- E ^ D| C ^ | B | | | | | v | v When a packet comes in FE1 port E and it want to forwaring to FE2 port B, it must across the Intra-NE FEs. There has two ways to generate the routing paths : 1, static configuration from FEM / CEM , 2, dynamic generated by system . Obviously the first method is not a good choice , so we focus on the latter one. We aleardy know the full topology from the CE topology table , this is designed and generated by Intra-NE topology discovery mechanism. But this topology table need to caculate and generate to the CE's Intra-routing table. For example , in this Figure , there exist two path from FE1 to FE2, so we must use some policy to select a better one which the cost is smaller. The method maybe like the OSPF SPF tree algorithm or other similar algorithm. See the CE topology table ---------------------------------------------- FE1 B FE2 D FE2 E FE3 D FE1 B FE2 C We will add a Intra-FIB in each FE , this table is distributed by master CE: i will add some structure such as nexthop(port) , nextNode(FE), so it looks like a table as below FE1 IFIB (part) ------------------------------------------------------------------------------------------------ FE1 B FE3 D FE2 D FE2 IFIB (part) ----------------------------------------------------------------------------------------------- FE2 E FE3 D FE3 D When the packet arrived at FE1 , Then FE1 find the Nexthop by searching FIB , and then searching IFIB , FE1 will know the routing path is from FE1 to FE3 then to FE2. In FE3 , only search the IFIB, the packet forward to FE2 with the correct path , then FE2 will forward it out the NE . This two table searching mechanism is a bit similar to such as MPLS or other VPN label pursh/pop action. The advantages as below : 1, The Intra-NE full topylogy need not known by each FE. 2, Intra-FE do not need the outer routing information. Best Regards Xiaoyi Guo ------------------------------------------------ Huawei Technologies. No. 3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing, P.R. China 100085 Tel: +86-10-8288-2290 Fax: +86-10-8288-2770 ------------------------------------------ --Boundary_(ID_la4wFKpEYU+YHmjJANgChw) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
All,
 
I'm currently putting a draft of the ForCES Intra-NE routing mechaniam,
and will submit it by Thusday.Below are the major points, please comment.
 
About ForCES Intra-NE routing mechanism
                 -----------------  
                 |      CE       |  
                 -----------------  
                A ^    B ^    C ^  
                 /       |       \  
                /      A v        \  
               /      ------- B    \  
              /    +->| FE3 |<-+    \  
             /     |C |     |  |     \  
          A v      |  -------  |      v A  
          -------B |           |E -------  
          | FE1 |<-+           +->| FE2 |  
          |     |<--------------->|     |  
          ------- C             D -------  
           E ^ D|                 C ^  | B  
             |  |                   |  |  
             |  v                   |  v    
 
When a packet comes in FE1 port E and it want to forwaring to FE2 port B,
it must across the Intra-NE FEs.
 
There has two ways to generate the routing paths :
1, static configuration from FEM / CEM ,
2, dynamic generated by system .
 
Obviously the first method is not a good choice , so we focus on the latter one.
We aleardy know the full topology from the CE topology table , this is designed and generated by
Intra-NE topology discovery mechanism.
 
But this topology table need to caculate and generate to the CE's Intra-routing table.
For example , in this Figure , there exist two path from FE1 to FE2, so we must use some policy
to select a better one which the cost is smaller. The method maybe like the OSPF SPF tree algorithm
or other similar algorithm.
 
See the CE topology table
----------------------------------------------
<Node>   <Port>   <Node>   <Port>
  FE1                B      FE2     D  
  FE2                E      FE3     D  
  FE1                B      FE2     C  

We will add a Intra-FIB in each FE , this table is distributed by master CE:
i will add some structure such as nexthop(port) , nextNode(FE), so it looks like a table as below
 
FE1 IFIB (part)
------------------------------------------------------------------------------------------------
<Node>   <Port>   <DstNode>   <Port>   <NextNode>   <NextPort>
  FE1             B              FE3            D            FE2                   D 
 
 FE2 IFIB (part)
-----------------------------------------------------------------------------------------------
<Node>   <Port>   <DstNode>   <Port>   <NextNode>   <NextPort>
  FE2            E                FE3             D           FE3              D      
 
When the packet arrived at FE1 , Then  FE1 find the Nexthop by searching FIB ,
and then searching IFIB , FE1 will know the routing path is from FE1 to FE3 then to FE2. In FE3 ,
only search the IFIB, the packet forward to FE2 with the correct path , then FE2 will forward it out the NE .
 
This two table searching mechanism is a bit similar to such as MPLS or other VPN label pursh/pop action.
 
The advantages as below :
1, The Intra-NE full topylogy need not known by each FE.
2, Intra-FE do not need the outer routing information.
 
 
Best Regards
 
Xiaoyi Guo
------------------------------------------------
Huawei Technologies.
No. 3 Xinxi Rd., Shang-Di Information Industry Base,
Hai-Dian District Beijing, P.R. China  100085
Tel:   +86-10-8288-2290
Fax:   +86-10-8288-2770
<mailto:xiaotian@huawei.com>
<http://www.huawei.com>
------------------------------------------
--Boundary_(ID_la4wFKpEYU+YHmjJANgChw)-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 08:35:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2IV-0000ow-SV for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 08:34:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14777 for ; Thu, 13 Oct 2005 08:34:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ2Sr-00021X-0o for forces-archive@IETF.ORG; Thu, 13 Oct 2005 08:45:52 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0110E125@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 8:34:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87919577 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 08:34:45 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 08:34:45 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9DBgiXK030530 for ; Thu, 13 Oct 2005 04:42:44 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-5QF6/ujOqpx76BL3vBRD" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129206881.6412.32.camel@localhost.localdomain> Date: Thu, 13 Oct 2005 08:34:41 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: updated text - rest of sec6 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 214c4b9fd640cafeeaa09a981bfa7351 --=-5QF6/ujOqpx76BL3vBRD Content-Type: text/plain Content-Transfer-Encoding: 7bit More text for review from sec 6.3 to end of section 6. This section is updated just to reflect the grammar updates - so nothing controversial. The sections that needs to be stared at the most is the config message followed by the table at the end (which needs to be validated against each message). I have added an extra column to the table to be more reflective of the grammar. The two core LFBs and the heartbeat section remain outstanding in this section. If i dont hear from Weiming by end of day, I will attack the HB message followed by the core LFBS. We are getting there ... cheers, jamal --=-5QF6/ujOqpx76BL3vBRD Content-Disposition: attachment; filename=sec6rest.txt Content-Type: text/plain; name=sec6rest.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 6.3. Semantics of message Direction Recall: The PL protocol provides a master(CE)-Slave(FE) relationship. The LFBs reside at the FE and are controlled by CE. When messages go from the CE, the LFB Selector (Class and instance) refers to the destination LFB selection which resides in the FE. When messages go from the FE->CE, the LFB Selector (Class and instance) refers to the source LFB selection which resides in the FE. 6.4. Association Messages The ForCES Association messages are used to establish and teardown associations between FEs and CEs. 6.4.1. Association Setup Message This message is sent by the FE to the CE to setup a ForCES association between them. This message could also be used by CEs to join a ForCES NE, however CE-to-CE communication is not covered by this protocol. Message transfer direction: FE to CE Message Header: The Message Type in the header is set MessageType= 'AssociationSetup'. The ACK flag in the header MUST be ignored, and the association setup message always expects to get a response from the message receiver (CE) whether the setup is successful or not. The Correlator field in the header is set, so that FE can correlate the response coming back from CE correctly. The Src ID (FE ID) may be set to O in the header which means that the FE would like the CE to assign a FE ID for the FE in the setup response message. Doria (Ed.), et al. Expires February 2, 2006 [Page 45] Internet-Draft ForCES August 2005 Message body: The association setup message body optionally consist of one or more LFB select TLV as described in Section 6.1.1.1.5. The association setup message only operates toward the FE Object and FE Protocol LFBs, therefore, the LFB class ID in the LFB select TLV only points to these two kinds of LFBs. There is only one FE object LFB and one FE protocol LFB per FE, therefore, the LFB instance IDs for the FE object LFB and the FE protocol LFB are usually assigned to the value 0x1. The Operation TLV in the LFB select TLV is defined as a 'REPORT' operation. More than one attribute may be announced in this message using REPORT operation to let the FE declare its configuration parameters in an unsolicited manner. These may contain attributes like the Heart Beat Interval parameter, etc. The Operation TLV for event notificationis is defined below. Operation TLV for Association Setup: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for REPORT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Only one operation type is defined for the association setup message: Type = "REPORT" --- this type of operation is for FE to report something to CE. PATH-DATA-TLV for REPORT: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The PATH-DATA-TLV for REPORT operation MAY contain FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data format. The RESULT-TLV is defined in Section 6.1.1.1.7 and the FULLDATA-TLV is defined in Section 6.1.1.1.8. To better illustrate the above PDU format, we show a tree structure for the format as below: Doria (Ed.), et al. Expires February 2, 2006 [Page 46] Internet-Draft ForCES August 2005 main hdr (eg type = Association setup) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | | +--- T = LFBselect | +-- LFBCLASSID = FE Protocol object | | +-- LFBInstance = 0x1 | +-- Path-data to one or more attibutes including suggested HB parameters Figure 15 6.4.2. Association Setup Response Message This message is sent by the CE to the FE in response to the Setup message. It indicates to the FE whether the setup is successful or not, i.e. whether an association is established. Message transfer direction: CE to FE Message Header: The Message Type in the header is set MessageType= 'AssociationSetupResponse'. The ACK flag in the header MUST be ignored, and the setup response message never expects to get any more response from the message receiver (FE). The Correlator field in the header MUST keep the same as that of the association setup message to be responded, so that the association setup message sender can correlate the response correctly. The Dst ID in the header will be set to some FE ID value assigned by the CE if the FE had requested that in the setup message (by SrcID = 0). Message body: The association setup response message body only consists of one TLV, the Association Result TLV, the format of which is as follows: is: Doria (Ed.), et al. Expires February 2, 2006 [Page 47] Internet-Draft ForCES August 2005 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = ASRresult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Setup Result | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (16 bits): The type of the TLV is "ASRresult". Length (16 bits): Length of the TLV including the T and L fields, in bytes. Association Setup Result (32 bits): This indicates whether the setup msg was successful or whether the FE request was rejected by the CE. the defined values are: 0 = success 1 = FE ID invalid 2 = too many associations 3 = permission denied 6.4.3. Association Teardown Message This message can be sent by the FE or CE to any ForCES element to end its ForCES association with that element. Message transfer direction: CE to FE, or FE to CE (or CE to CE) Message Header: The Message Type in the header is set MessageType= "AssociationTeardown". The ACK flag MUST be ignored, and the association teardown message never expects to get any further response from the message receiver. The correlator field in the header is also ignored owing to no further response expected. Message Body: The association teardown message body only consists of one TLV, the Association Teardown Reason TLV, the format of which is as follows: Doria (Ed.), et al. Expires February 2, 2006 [Page 48] Internet-Draft ForCES August 2005 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = ASTreason | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Teardown Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (16 bits): The type of the TLV is "ASTreason". Length (16 bits): Length of the TLV including the T and L fields, in bytes. Teardonw Reason (32 bits): This indicates the reason why the association is being terminated. Several reason codes are defined as follows. 0 - normal teardown by administrator 1 - error - loss of heartbeats 2 - error - out of bandwidth 3 - error - out of memory 4 - error - application crash 255 - error - other or unspecified 6.5. Configuration Messages The ForCES Configuration messages are used by CE to configure the FEs in a ForCES NE and report the results back to the CE. 6.5.1. Config Message This message is sent by the CE to the FE to configure LFB attributes in the FE. This message is also used by the CE to subscribe/ unsubscribe to LFB events. As usual, a config message is composed of a common header followed by a message body that consists of one or more TLV data format. Detailed description of the message is as below. Doria (Ed.), et al. Expires February 2, 2006 [Page 49] Internet-Draft ForCES August 2005 Message transfer direction: CE to FE Message Header: The Message Type in the header is set MessageType= 'Config'. The ACK flag in the header can be set to any value defined in Section 5.1, to inidcate whether or not a response from FE is expected by the message ( the flag is set to 'NoACK' or 'AlwaysACK'), or to indicate in which case a response is generated (the flag is set to 'SuccessACK' or 'FailureACK'). The default behavior for the ACK flag is set to always expect a full response from FE. This happens when the ACK flag is not set to any defined value. The correlator field in the messge header MUST be set if a response is expected, so that CE can correlate the response correctly. The correlator field can be ignored if no response is expected. Message body: The config message body MUST consist of at least one LFB select TLV as described in Section 6.1.1.1.5. The Operation TLV in the LFB select TLV is defined below. Operation TLV for Config: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The operation type for config message. two types of operations for the config message are defined: Type = "SET" --- this operation is to set LFB attributes Type = "DEL" --- this operation to delete some LFB attributes PATH-DATA-TLV: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The restriction on the use of PATH-DATA-TLV for SET operation is, it MUST contain either a FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT-TLV. The restriction on the use of PATH-DATA-TLV for DEL operation is it MAY contain FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT- TLV. The RESULT-TLV is defined in Section 6.1.1.1.7 and FULLDATA Doria (Ed.), et al. Expires February 2, 2006 [Page 50] Internet-Draft ForCES August 2005 and SPARSEDATA TLVs is defined in Section 6.1.1.1.8. *Note: For Event subscription, the events will be defined by the individual LFBs. To better illustrate the above PDU format, we show a tree structure for the format as below: main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = operation { SET } | | | | | +-- // one or more path targets | | // associated with FULL or SPARSEDATA TLV(s) | | | +-- T = operation { DEL } | | | | | +-- // one or more path targets 6.5.2. Config Response Message This message is sent by the FE to the CE in response to the Config message. It indicates whether the Config was successful or not on the FE and also gives a detailed response regarding the configuration result of each attribute. Message transfer direction: FE to CE Message Header: The Message Type in the header is set MessageType= 'Config Response'. The ACK flag in the header is always ignored, and the config response message never expects to get any further response from the message receiver (CE). The Correlator field in the header MUST keep the same as that of the config message to be responded, so that the config message sender can correlate the response with the original message correctly. Doria (Ed.), et al. Expires February 2, 2006 [Page 51] Internet-Draft ForCES August 2005 Message body: TThe config message body MUST consist of at least one LFB select TLV as described in Section 6.1.1.1.5. The Operation TLV in the LFB select TLV is defined below. Operation TLV for Config Response: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The operation type for config response message. Two types of operations for the config response message are defined: Type = "SET-RESPONSE" --- this operation is for the response of SET operation of LFB attributes Type = "DEL-RESPONSE" --- this operation is for the response of DELete operation of LFB attributes PATH-DATA-TLV: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The restriction on the use of PATH-DATA-TLV for SET- RESPONSE operation is it MUST contain RESULT-TLV(s). The restriction on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV is defined in Section 6.1.1.1.7. 6.6. Query Messages The ForCES query messages are used by the CE to query LFBs in the FE for informations like LFB attributes, capabilities, statistics, etc. Query Messages include the Query Message and the Query Response Message. 6.6.1. Query Message As usual, a query message is composed of a common header and a message body that consists of one or more TLV data format. Detailed description of the message is as below. Doria (Ed.), et al. Expires February 2, 2006 [Page 52] Internet-Draft ForCES August 2005 Message transfer direction: from CE to FE. Message Header: The Message Type in the header is set to MessageType= 'Query'. The ACK flag in the header is always ignored, and a full response for a query message is always expected. The Correlator field in the header is set, so that CE can locate the response back from FE correctly. Message body: The query message body MUST consist of at least one LFB select TLV as described in Section 6.1.1.1.5. The Operation TLV in the LFB select TLV is defined below. Operation TLV for Query: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = GET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for GET | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21 Type: The operation type for query. One operation type is defined: Type = "GET" --- this operation is to request to get LFB attributes. PATH-DATA-TLV for GET: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The restriction on the use of PATH-DATA-TLV for GET operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV and RESULT-TLV in the data format. To better illustrate the above PDU format, we show a tree structure for the format as below: Doria (Ed.), et al. Expires February 2, 2006 [Page 53] Internet-Draft ForCES August 2005 main hdr (type = Query) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = operation { GET } | | | | | +-- // one or more path targets | | | +-- T = operation { GET } | | | | | +-- // one or more path targets | | Figure 22 6.6.2. Query Response Message When receiving a query message, the receiver should process the message and come up with a query result. The receiver sends the query result back to the message sender by use of the Query Response Message. The query result can be the information being queried if the query operation is successful, or can also be error codes if the query operation fails, indicating the reasons for the failure. A query response message is also composed of a common header and a message body consists of one or more TLVs describing the query result. Detailed description of the message is as below. Message transfer direction: from FE to CE. Message Header: The Message Type in the header is set to MessageType= 'QueryResponse'. The ACK flag in the header is ignored. As a response itself, the message does not expect a further response anymore. The Correlator field in the header MUST keep the same as that of the query message to be responded, so that the query message sender can keep track of the response. Doria (Ed.), et al. Expires February 2, 2006 [Page 54] Internet-Draft ForCES August 2005 Message body: The query response message body MUST consist of at least one LFB select TLV as described in Section 6.1.1.1.5. The Operation TLV in the LFB select TLV is defined below. Operation TLV for Query Response: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = GET-RESPONSE | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for GET-RESPONSE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23 Type: The operation type for query response. One operation type is defined: Type = "GET-RESPONSE" --- this operation is to response to get operation of LFB attributes. PATH-DATA-TLV for GET-RESPONSE: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA TLV, FULLDATA TLV and/or RESULT-TLV(s) in the data encoding. The RESULT-TLV is defined in Section 6.1.1.1.7 and the SPARSEDATA and FULLDATA TLVs are defined in Section 6.1.1.1.8. 6.7. Event Notification Message Event Notification Message is used by FE to asynchronously notify CE of events that happen in the FE. All events happen in FE are subscribable by CE. A config message is used by CE to subscribe/unsubscribe for an event in FE. To subscribe to an event is usually by specifying to the path of such an event as described by FE-Model and defined by LFB library. As usual, an Event Notification Message is composed of a common header and a message body that consists of one or more TLV data format. Detailed description of the message is as below. Doria (Ed.), et al. Expires February 2, 2006 [Page 55] Internet-Draft ForCES August 2005 Message Transfer Direction: FE to CE Message Header: The Message Type in the message header is set to MessageType = 'EventNotification'. The ACK flag in the header MUST be ignored, and the event notification message does not expect any response from the receiver. The Correlator field in the header is also ignored because the response is not expected. Message Body: The event notification message body MUST consist of at least one LFB select TLV as described in Section 6.1.1.1.5. The Operation TLV in the LFB select TLV is defined below. Operation TLV for Event Notification: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for REPORT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Only one operation type is defined for the event notification message: Type = "REPORT" --- this type of operation is for FE to report something to CE. PATH-DATA-TLV for REPORT: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The PATH-DATA-TLV for REPORT operation MAY contain FULLDATA or SPARSEDATA TLV(s) but MUST NOT contain any RESULT-TLV in the data format. To better illustrate the above PDU format, we show a tree structure for the format as below: Doria (Ed.), et al. Expires February 2, 2006 [Page 56] Internet-Draft ForCES August 2005 main hdr (type = Event Notification) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = operation { REPORT } | | | | | +-- // one or more path targets | | // associated with FULL/SPARSE DATA TLV(s) | +-- T = operation { REPORT } | | | | | +-- // one or more path targets | | // associated with FULL/SPARSE DATA TLV(s) Figure 25 6.8. Packet Redirect Message Packet redirect message is used to transfer data packets between CE and FE. Usually these data packets are IP packets, though they may sometimes associated with some metadata generated by other LFBs in the model, or they may occasionally be other protocol packets, which usually happen when CE and FE are jointly implementing some high- touch operations. Packets redirected from FE to CE are the data packets that come from forwarding plane, and usually are the data packets that need high-touch operations in CE,or packets for which the IP destination address is the NE. Packets redirected from CE to FE are the data packets that come from the CE and are decided by CE to put into forwarding plane in FE. Supplying such a redirect path between CE and FE actually leads to a possibility of this path being DoS attacked. Attackers may maliciously try to send huge spurious packets that will be redirected by FE to CE, making the redirect path been congested. ForCES protocol and the TML layer will jointly supply approaches to prevent such DoS attack. To define a specific 'Packet Redirect Message' makes TML and CE able to distinguish the redirect messages from other ForCES protocol messages. By properly configuring related LFBs in FE, a packet can also be mirrored to CE instead of purely redirected to CE, i.e., the packet Doria (Ed.), et al. Expires February 2, 2006 [Page 57] Internet-Draft ForCES August 2005 is duplicated and one is redirected to CE and the other continues its way in the LFB topology. The Packet Redirect Message data format is formated as follows: Message Direction: CE to FE or FE to CE Message Header: The Message Type in the header is set to MessageType= 'PacketRedirect'. The ACK flags in the header MUST be ignored, and no response is expected by this message. The correlator field is also ignored because no response is expected. Message Body: Consists of (at least) one or more than one TLV that describes the packet redirection. The TLV is specifically a Redirect TLV (with the TLV Type="Redirect"). Detailed data format of a Redirect TLV for packet redirect message is as below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Redirect | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirect Data TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26 LFB class ID: There are only two possible LFB classes here, the 'RedirectSink' LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from FE to CE, the LFB class should be 'RedirectSink'. If the message is from CE to FE, the LFB class should be 'RedirectSource'. Instance ID: Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. Doria (Ed.), et al. Expires February 2, 2006 [Page 58] Internet-Draft ForCES August 2005 Meta Data TLV: This is a TLV that specifies meta-data associated with followed redirected data. The TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = META-DATA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ILV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ILV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27 Meta Data ILV: This is an Identifier-Length-Value format that is used to describe one meta data. The ILV has the format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data Value | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Meta Data ID is an identifier for the meta data, which is statically assigned by the LFB definition. This actually implies a Meta Data ID transcoding mechanism may be necessary if a metadata traverses several LFBs while these LFBs define the metadata with different Meta Data IDs. Usually there are two meta data that are necessary for CE-FE redirect operation. One is the redirected data type (e.g., IP packet, TCP packet, or UDP Packet). For an FE->CE redirect operation, redirected packet type meta data is usually a meta data specified by a Classifier LFB that filter out redirected packets from packet stream and sends the packets to Redirect Sink LFB. For an CE->FE redirect operation, the redirected packet type meta data is usually directly generated by CE. Another meta data that should be associated with redirected data Doria (Ed.), et al. Expires February 2, 2006 [Page 59] Internet-Draft ForCES August 2005 is the port number in a redirect LFB. For a RedirectSink LFB, the port number meta data tells CE from which port in the lFB the redirected data come. For a RedriectSource LFB, via the meta data, CE tells FE which port in the LFB the redirected data should go out. Redirect Data TLV This is a TLV describing one packet of data to be directed via the redirect operation. The TLV format is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = REDIRECTDATA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirected Data | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Redirected Data: This field presents the whole packet that is to be redirected. The packet should be 32bits aligned. 6.9. Heartbeat Message The Heartbeat (HB) Message is used for one ForCES element (FE or CE) to asynchronously notify one or more other ForCES elements in the same ForCES NE on its liveness. A Heartbeat Message is sent by a ForCES element periodically. The time interval for FE to send heartbeats is managed as an attribute of FE protocol LFB, and can be set by CE via a config message. A little different from other protocol messages, a Heartbeat message is only composed of a common header, with the message body left empty. Detailed description of the message is as below. Message Transfer Direction: FE to CE, or CE to FE Message Header: The Message Type in the message header is set to MessageType = 'Heartbeat'. The ACK flag in the header MUST be ignored, and no response is expected by the Heartbeat Message. The correlator field in the header is also ignored then. Message Body: The message body is empty for the Heartbeat Message. Doria (Ed.), et al. Expires February 2, 2006 [Page 60] Internet-Draft ForCES August 2005 6.10. Operation Summary The following table summarizes the TLVs that compose messages, and the applicabiity of operation TLVs to the messages. +---------------------------+-----------+---------------------------+ | Messages | TLVs | Operations | +---------------------------+-----------+---------------------------+ | Association Setup | LFBselect | REPORT | | | | | | Association Setup | ASRresult | None | | Response | | | | | | | | Association Teardown | ASTreason | None | | | | | | Config | LFBselect | SET, DEL | | | | | | Config Response | LFBselect | SET-RESPONSE, | | | | DEL-RESPONSE | | | | | | Query | LFBselect | GET | | | | | | Query Response | LFBselect | GET-RESPONSE | | | | | | Event Notification | LFBselect | REPORT | | | | | | Packet Redirect | Redirect | None | | | | | | Heartbeat | None | None | +---------------------------+-----------+---------------------------+ The following talbe summarises the applicability of the FULL/SPARSE DATA TLV and the RESULT TLV to the Operation TLVs. Doria (Ed.), et al. Expires February 2, 2006 [Page 61] Internet-Draft ForCES August 2005 +--------------+--------------+----------------+------------+ | Operations | FULLDATA TLV | SPARSEDATA TLV | RESULT TLV | +--------------+--------------+----------------+------------+ | SET | MAY | MAY | MUST NOT | | | | | | | SET-RESPONSE | MAY | MUST NOT | MUST | | | | | | | DEL | MAY | MAY | MUST NOT | | | | | | | DEL-RESPONSE | MAY | MUST NOT | MUST | | | | | | | GET | MUST NOT | MUST NOT | MUST NOT | | | | | | | GET-RESPONSE | MUST | MUST NOT | MAY | | | | | | | REPORT | MAY | MUST NOT | MUST NOT | +--------------+--------------+----------------+------------+ Doria (Ed.), et al. Expires February 2, 2006 [Page 62] Internet-Draft ForCES August 2005 --=-5QF6/ujOqpx76BL3vBRD-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 09:02:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2jB-0007rS-5U for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 09:02:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15977 for ; Thu, 13 Oct 2005 09:02:28 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ2th-0002h5-CV for forces-archive@IETF.ORG; Thu, 13 Oct 2005 09:13:25 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0110E11B@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 9:02:28 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87921281 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 09:02:27 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 09:02:27 -0400 Received: from [71.254.23.91] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12660002 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 07:01:53 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <044f01c5cfdc$ab642930$22646e0a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051013085739.02f92610@localhost> Date: Thu, 13 Oct 2005 09:02:21 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: ForCES Intra-NE routing mechanism To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <044f01c5cfdc$ab642930$22646e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a I am not sure I follow this discussion. 1) The CE can use any algorithm it likes to calculate paths. (That applies both to intra-NE paths and to normal routing. ForCES does not care what path computation algorithm is used by the CE.) 2) I don't see the value in creating a new kind of forwarding table. For each FE, the forwarding table it is given ought to translate an IP prefix into a next hop, and the next hop into an egress port. You seem to be trying to add a third layer of mapping. The benefit I can see for such a thing might be that it could reduce slightly the differences in the tables across the FEs. However, I would be really unhappy at mandating such an architecture. Yours, Joel At 05:58 AM 10/13/2005, Xiaoyi Guo wrote: >All, > >I'm currently putting a draft of the ForCES Intra-NE routing mechaniam, >and will submit it by Thusday.Below are the major points, please comment. > >About ForCES Intra-NE routing mechanism > ----------------- > | CE | > ----------------- > A ^ B ^ C ^ > / | \ > / A v \ > / ------- B \ > / +->| FE3 |<-+ \ > / |C | | | \ > A v | ------- | v A > -------B | |E ------- > | FE1 |<-+ +->| FE2 | > | |<--------------->| | > ------- C D ------- > E ^ D| C ^ | B > | | | | > | v | v > >When a packet comes in FE1 port E and it want to forwaring to FE2 port B, >it must across the Intra-NE FEs. > >There has two ways to generate the routing paths : >1, static configuration from FEM / CEM , >2, dynamic generated by system . > >Obviously the first method is not a good choice , so we focus on the >latter one. >We aleardy know the full topology from the CE topology table , this is >designed and generated by >Intra-NE topology discovery mechanism. > >But this topology table need to caculate and generate to the CE's >Intra-routing table. >For example , in this Figure , there exist two path from FE1 to FE2, so we >must use some policy >to select a better one which the cost is smaller. The method maybe like >the OSPF SPF tree algorithm >or other similar algorithm. > >See the CE topology table >---------------------------------------------- > > FE1 B FE2 D > FE2 E FE3 D > FE1 B FE2 C > >We will add a Intra-FIB in each FE , this table is distributed by master CE: >i will add some structure such as nexthop(port) , nextNode(FE), so it >looks like a table as below > >FE1 IFIB (part) >------------------------------------------------------------------------------------------------ > > FE1 B FE3 D FE2 > D > > FE2 IFIB (part) >----------------------------------------------------------------------------------------------- > > FE2 E FE3 D FE3 > D > >When the packet arrived at FE1 , Then FE1 find the Nexthop by searching >FIB , >and then searching IFIB , FE1 will know the routing path is from FE1 to >FE3 then to FE2. In FE3 , >only search the IFIB, the packet forward to FE2 with the correct path , >then FE2 will forward it out the NE . > >This two table searching mechanism is a bit similar to such as MPLS or >other VPN label pursh/pop action. > >The advantages as below : >1, The Intra-NE full topylogy need not known by each FE. >2, Intra-FE do not need the outer routing information. > > >Best Regards > >Xiaoyi Guo >------------------------------------------------ >Huawei Technologies. >No. 3 Xinxi Rd., Shang-Di Information Industry Base, >Hai-Dian District Beijing, P.R. China 100085 >Tel: +86-10-8288-2290 >Fax: +86-10-8288-2770 ><mailto:xiaotian@huawei.com> > >------------------------------------------ From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 09:16:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2wf-0002Tj-Af for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 09:16:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16691 for ; Thu, 13 Oct 2005 09:16:24 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ378-000369-M9 for forces-archive@IETF.ORG; Thu, 13 Oct 2005 09:27:19 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0110E1B6@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 9:16:25 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87921799 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 09:16:24 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 09:16:24 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9DCO4XK030778; Thu, 13 Oct 2005 05:24:04 -0700 (PDT) References: <044f01c5cfdc$ab642930$22646e0a@china.huawei.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129209360.6412.55.camel@localhost.localdomain> Date: Thu, 13 Oct 2005 09:16:00 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: ForCES Intra-NE routing mechanism Comments: To: Xiaoyi Guo To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <044f01c5cfdc$ab642930$22646e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Hello, On Thu, 2005-13-10 at 17:58 +0800, Xiaoyi Guo wrote: > All, > > I'm currently putting a draft of the ForCES Intra-NE routing > mechaniam, > and will submit it by Thusday.Below are the major points, please > comment. > > About ForCES Intra-NE routing mechanism > ----------------- > | CE | > ----------------- > A ^ B ^ C ^ > / | \ > / A v \ > / ------- B \ > / +->| FE3 |<-+ \ > / |C | | | \ > A v | ------- | v A > -------B | |E ------- > | FE1 |<-+ +->| FE2 | > | |<--------------->| | > ------- C D ------- > E ^ D| C ^ | B > | | | | > | v | v > > When a packet comes in FE1 port E and it want to forwaring to FE2 port > B, it must across the Intra-NE FEs. > > There has two ways to generate the routing paths : > 1, static configuration from FEM / CEM , > 2, dynamic generated by system . > > Obviously the first method is not a good choice , so we focus on the > latter one. I am not sure i understood what you mean by FEM/CEM doing this. The CE does the update in the above scenario. The static case will not have any routing protocol (such as OSPF) running on the CE whereas the dynamic case will. > We aleardy know the full topology from the CE topology table , this is > designed and generated by Intra-NE topology discovery mechanism. > right. > But this topology table need to caculate and generate to the CE's > Intra-routing table. right - i.e the NH entry for each route. > For example , in this Figure , there exist two path from FE1 to FE2, > so we must use some policy to select a better one which the cost is > smaller. The method maybe like the OSPF SPF tree algorithm > or other similar algorithm. > Yes, this is described in the Topology draft. > See the CE topology table > ---------------------------------------------- > > FE1 B FE2 D > FE2 E FE3 D > FE1 B FE2 C > > We will add a Intra-FIB in each FE , this table is distributed by > master CE: > i will add some structure such as nexthop(port) , nextNode(FE), so it > looks like a table as below > > FE1 IFIB (part) > ------------------------------------------------------------------------------------------------ > > FE1 B FE3 D FE2 > D > > FE2 IFIB (part) > ----------------------------------------------------------------------------------------------- > > FE2 E FE3 D FE3 > D > Depends on the FE; one could look at the NextNode:NextPort as part of the NextHop description in the forwarding. i.e the IFIB becomes part of the NH table used by the FIB. > When the packet arrived at FE1 , Then FE1 find the Nexthop by > searching FIB , and then searching IFIB , FE1 will know the routing > path is from FE1 to FE3 then to FE2. In FE3 , > only search the IFIB, the packet forward to FE2 with the correct > path , then FE2 will forward it out the NE . > Again implementation detail depending on the FE (the ASIC and the Forwarding fabric used to be precise). The rules are if you are going to do that you must make sure the ttl does not get decremented more than once. > This two table searching mechanism is a bit similar to such as MPLS or > other VPN label pursh/pop action. > > The advantages as below : > 1, The Intra-NE full topylogy need not known by each FE. > 2, Intra-FE do not need the outer routing information. > I have to say i see everything you have described as implementation details. i.e The FE Object LFB[1] lists the concept of neighbors. These neighbors are going to be derived from the topology LFB. And from that info you can derive the NH details for routing. How you do this is dependent on the chip and the interconnect. cheers, jamal [1]The neighbor information is insufficient at the moment by claiming that neighbors can only have MAC addresses and ignores the forwarding path could be over SPI3/4 or even over purely L2 ethernet for example - we have had many debates on the list and that debate is going to resurface RealSoonNow. From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 10:29:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ457-0007j7-Rn for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 10:29:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21064 for ; Thu, 13 Oct 2005 10:29:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ4Fb-0005Iy-OW for forces-archive@IETF.ORG; Thu, 13 Oct 2005 10:40:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0110E39B@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 10:29:13 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87925419 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 10:29:12 -0400 Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 10:29:12 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j9DETBrU114218 for ; Thu, 13 Oct 2005 14:29:11 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9DETBqB169592 for ; Thu, 13 Oct 2005 15:29:11 +0100 Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j9DETB58007508 for ; Thu, 13 Oct 2005 15:29:11 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j9DETAdK007488; Thu, 13 Oct 2005 15:29:11 +0100 Received: from [127.0.0.1] ([9.4.210.49]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA60308; Thu, 13 Oct 2005 16:29:06 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <434BB83B.5050100@zurich.ibm.com> <03f601c5cfcc$311fc1d0$22646e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.uk.ibm.com id j9DETBrU114218 Approved-By: Robert Haas Message-ID: <434E6F38.9010508@zurich.ibm.com> Date: Thu, 13 Oct 2005 16:29:12 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: ForCES MIB: 1st draft Comments: To: Guo xiaoyi To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <03f601c5cfcc$311fc1d0$22646e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Hi Xiaoyi, Guo xiaoyi wrote: >hi, Robert, > >i am a newer come in this group and wish i wont give a bad comment ;) > =20 > >i have not seen the draft yet, but i want to express some suggestions. > >There are two way to get the MIB information , one way is each time CE q= uery FE(s) and FE(s) return the=20 >neccesary informaiton to CE. Another way is FE(s) send the information t= o CE within a time interval.=20 > > =20 > Correct, this can for instance apply to packet counters, etc, that are=20 maintained at the FE. The CE must somehow retrieve this information from=20 the FE in order to reflect the current value in the corresponding MIB. I=20 suppose you implied that ForCES is used to retrieve this information.=20 Which of the two methods (real-time or periodical) to use is an=20 implementation issue. >If we use the first method , then we could get the real-time information= of FE(s) , but we chould not=20 >decide which old associations to remove from the MIB in time. If we use = the latter one , we can decide it but we >maybe can not get real-time information , its just the old informaiton = of the last time interval. > > =20 > I am not sure I understand what you mean by "we should not decide which=20 old associations to remove from the MIB in time". Maybe take a look at=20 the draft I am sending now (more specifically Section 3) and please=20 rephrase your point. Regards, -Robert >cheers >Xiaoyi Guo > > > >----- Original Message -----=20 >From: " Robert Haas >Subject: ForCES MIB: 1st draft > > =20 > >>All, >>I'm currently putting together a first draft of the ForCES MIB (a=20 >>requirement to proceed with our protocol draft), and will submit=20 >>it it=20 >>by Monday. >>Below are the major points, please comment. >> >>The ForCES MIB is a read-only MIB used to monitor the state of=20 >>associations in an NE. For each association identified by the pair=20 >>CE ID=20 >>and FE ID, the following information is shown: >> >>- Current state of the association: >> >> UP: the CE(s) indicated by the CE ID and FE(s)=20 >>indicated by=20 >>the FE ID are associated. >> DOWN: the CE(s) indicated by the CE ID and FE(s) indicated by=20 >>the=20 >>FE ID are not associated AND the CE(s) indicated by the CE ID is=20 >>sending=20 >>Association Setup messages. >>Note that associations that are DOWN and for which no Association=20 >>Setup=20 >>messages are being sent by the CE are NOT listed in the MIB=20 >>(otherwise=20 >>how do we decide which old associations to remove from the MIB ?) >> >>- Association history: >> Date/time when the association came to the UP state. >> (Number of commands executed or some indications of the ForCES=20 >>control traffic ?) >> >>- Hearbeat timers values of the FE and CE for this association. >> >>- Heartbeat timer settings of the FE and CE for this association:=20 >> >> ENABLED: hearbeats are transmitted (by default virtual=20 >>piggybacking=20 >>is used) >> DISABLED: heartbeats are not transmitted >> >>- Backup information: the FE(s)/CE(s) that are configured to work=20 >>as=20 >>backups for this association (necessary ? useful ?) >> >> >> >>Regards, >> >>--=20 >>Dr. Robert R. Haas >>IBM Zurich Research Laboratory >>S?umerstrasse 4 >>CH-8803 R=FCschlikon/Switzerland >>phone +41-44-724-8698 fax +41-44-724-8578 =20 >>http://www.zurich.ibm.com/~rha >> =20 >> > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 10:33:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ49Z-0000Pv-Vr for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 10:33:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21372 for ; Thu, 13 Oct 2005 10:33:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ4K6-0005Rv-Mr for forces-archive@IETF.ORG; Thu, 13 Oct 2005 10:44:47 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0110E387@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 10:33:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87926142 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 10:33:50 -0400 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 10:33:50 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j9DEXnrO115490 for ; Thu, 13 Oct 2005 14:33:49 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9DEXnLh235412 for ; Thu, 13 Oct 2005 16:33:49 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j9DEXncT024124 for ; Thu, 13 Oct 2005 16:33:49 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j9DEXm3m024097 for ; Thu, 13 Oct 2005 16:33:48 +0200 Received: from [127.0.0.1] (dhcp70-16.zurich.ibm.com [9.4.70.16]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA55506 for ; Thu, 13 Oct 2005 16:33:48 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <434BB83B.5050100@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Robert Haas Message-ID: <434E7051.4080500@zurich.ibm.com> Date: Thu, 13 Oct 2005 16:33:53 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: ForCES MIB: 1st draft To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <434BB83B.5050100@zurich.ibm.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit All, Below is the 1st draft, which raises a few issues. Regards, -Robert ForCES MIB (draft version 00-a) 0. Abstract This document specifies the ForCES MIB. 1. Introduction The ForCES MIB is a read-only MIB that captures information related to the ForCES protocol. This includes state information about the associations between CE(s) and FE(s) in the NE. [Note: anything else besides associations that the MIB should include?] The ForCES MIB does not include information that is specified in other MIBs, such as packet counters for interfaces, etc. The information in the ForCES MIB relative to associations includes more specifically: - identifiers of the elements in the association - state of the association - configuration parameters of the association - statistics of the association The relevant references from the ForCES requirements and architecture documents are repeated below: Requirements RFC 3654 http://www.ietf.org/rfc/rfc3654.txt Section 4, point 4: 4) A NE MUST support the appearance of a single functional device. For example, in a router, the TTL of the packet should be decremented only once as it traverses the NE regardless of how many FEs through which it passes. However, external entities (e.g., FE managers and CE managers) MAY have direct access to individual ForCES protocol elements for providing information to transition them from the pre- association to post-association phase. Section 4, point 14: 1. The ability for a management tool (e.g., SNMP) to be used to read (but not change) the state of FE SHOULD NOT be precluded. 2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to change the state of a FE in a manner that affects overall NE behavior without the CE being notified. Architecture RFC 3746 http://www.ietf.org/rfc/rfc3746.txt Section 3.3: CE managers may be physically and logically separate entities that configure the CE with FE information via such mechanisms as COPS-PR [7] or SNMP [5]. Section 5.7: 5.7. Application Layer -- Network Management Protocol RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP". In general, for the post-association phase, most external management tasks (including SNMP) should be done through interaction with the CE in order to support the appearance of a single functional device. Therefore, it is recommended that an SNMP agent be implemented by CEs and that the SNMP messages received by FEs be redirected to their CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here such that CEs act in the role of master agent to process SNMP protocol messages while FEs act in the role of subagent to provide access to the MIB objects residing on FEs. AgentX protocol messages between the master agent (CE) and the subagent (FE) are encapsulated and transported via ForCES, just like data packets from any other application layer protocols. 2. Design of ForCES MIB As state information is distributed across FEs and CEs, the following alternatives may be considered: 1) CE MIBs Each CE in the NE implements a CE MIB. The external SNMP-based management tool must therefore be aware of each CE in order to obtain a complete view of the NE by collecting state information obtained from each CE MIB. [Note: this may or may not comply with requirement #4 ("A NE MUST support the appearance of a single functional device")] 2) single NE MIB An entity in the NE implements an NE MIB that aggregates state information collected from each CE (CEs are possibly from various vendors). This requires a standard protocol in order to support multi-vendor environment. AgentX with the NE as the master and the CE(s) as the agent(s) may be considered here. [Note: comments on the suitability of AgentX ?] [Note: none of the two alternatives are ideal ...] 3. Capturing State Before Association Establishment The ForCES protocol may be used by the CE to query the FE Protocol LFB about some of the configuration parameters. But such queries may obviously be issued only once the association is established. In the ForCES protocol, the FE first issues an Association Setup Request message to the CE which in turns responds with an Association Setup Response message. It may be useful to capture in the MIB in which state the association is seen from each of the FE and the CE sides, as a means to detect PL-level communication anomalies. For instance, from the FE side, the association is in the ATTEMPT state as long as no response to the Association Setup message has been received from the CE. Similarly, the association is in the ESTABLISHING state as long as no message has been received from the FE after the CE has issued a positive Association Setup Response message (this is because configuration mistakes in the FE may cause messages from the CE to be ignored, and the MIB could help in tracing such errors). The transient state in the FE until the association is established cannot be queried using ForCES. [Note: If such information is critical, then an FE MIB has to be provided that can be queried separately] 4. MIB Definition(s) For each association identified by the pair CE ID and FE ID, the following information is included in the MIB: [Note: the MIB includes all associations for the particular CE in the case of a CE MIB, same for FE MIBs (if any), or all associations in the NE in the case of a NE MIB] - Current state of the association: UP: the CE(s) indicated by the CE ID and FE(s) indicated by the FE ID are associated. ESTABLISHING/ATTEMPT: transient state unitl the association is established. See section 3 above for details. Note that associations that are not UP and for which no association setup is in progress are NOT listed in the MIB. [Note: otherwise how do we decide which old associations to remove from the MIB ?] - Hearbeat timers values of the FE and CE for this association. - Heartbeat timer settings of the FE and CE for this association: ENABLED: hearbeats are transmitted (by default virtual piggybacking is used) DISABLED: heartbeats are not transmitted - Backup information: the FE(s)/CE(s) that are configured to work as backups for this association. [Note: is this necessary, useful ?] - Association statistics: Date/time when the association came to the UP state. [Note: what about the Number of commands executed or some indications of the ForCES control traffic ?] TBD: actual MIB specification. From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 10:51:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4Qp-0005ZM-1y for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 10:51:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22081 for ; Thu, 13 Oct 2005 10:51:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ4bG-0005qJ-02 for forces-archive@IETF.ORG; Thu, 13 Oct 2005 11:02:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0110E387@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 10:51:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87926941 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 10:51:33 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 10:51:32 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 13 Oct 2005 23:31:56 +0800 (CST) References: <1129206881.6412.32.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <002001c5d005$a402fbc0$1f12fea9@wwm1> Date: Thu, 13 Oct 2005 22:51:47 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: updated text - rest of sec6 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Jamal, attached is the update I tried for the HB message. Pls feel free to modify it. Thank, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Thursday, October 13, 2005 8:34 PM Subject: updated text - rest of sec6 > > More text for review from sec 6.3 to end of section 6. This section is > updated just to reflect the grammar updates - so nothing controversial. > The sections that needs to be stared at the most is the config message > followed by the table at the end (which needs to be validated against > each message). I have added an extra column to the table to be more > reflective of the grammar. > > The two core LFBs and the heartbeat section remain outstanding in this > section. If i dont hear from Weiming by end of day, I will attack the HB > message followed by the core LFBS. We are getting there ... > > > cheers, > jamal > From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 10:57:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4Wk-0006sF-HP for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 10:57:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22348 for ; Thu, 13 Oct 2005 10:57:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ4hG-000604-S4 for forces-archive@IETF.ORG; Thu, 13 Oct 2005 11:08:44 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0110E49A@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 10:57:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87927213 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 10:57:47 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 10:57:46 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.2105028806; Thu, 13 Oct 2005 23:38:10 +0800 (CST) References: <1129206881.6412.32.camel@localhost.localdomain> <002001c5d005$a402fbc0$1f12fea9@wwm1> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <006901c5d006$831c0540$1f12fea9@wwm1> Date: Thu, 13 Oct 2005 22:58:03 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: updated text - rest of sec6 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 I don't know why the attached file does not appear. just resend it. ----- Original Message ----- From: "Weiming Wang" > Jamal, > > attached is the update I tried for the HB message. Pls feel free to modify it. > > Thank, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > To: > Sent: Thursday, October 13, 2005 8:34 PM > Subject: updated text - rest of sec6 > > > > > > More text for review from sec 6.3 to end of section 6. This section is > > updated just to reflect the grammar updates - so nothing controversial. > > The sections that needs to be stared at the most is the config message > > followed by the table at the end (which needs to be validated against > > each message). I have added an extra column to the table to be more > > reflective of the grammar. > > > > The two core LFBs and the heartbeat section remain outstanding in this > > section. If i dont hear from Weiming by end of day, I will attack the HB > > message followed by the core LFBS. We are getting there ... > > > > > > cheers, > > jamal > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 11:05:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ4eM-0001MP-3y for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:05:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22671 for ; Thu, 13 Oct 2005 11:05:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ4os-0006Be-BL for forces-archive@IETF.ORG; Thu, 13 Oct 2005 11:16:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0110E3D8@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 11:05:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87927884 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 11:05:38 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 11:05:37 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 13 Oct 2005 23:46:06 +0800 (CST) References: <1129206881.6412.32.camel@localhost.localdomain> <002001c5d005$a402fbc0$1f12fea9@wwm1> <006901c5d006$831c0540$1f12fea9@wwm1> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <007501c5d007$9ee23320$1f12fea9@wwm1> Date: Thu, 13 Oct 2005 23:05:56 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: updated text - rest of sec6 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 I don't know what happened. Just post it inside then. 6.9. Heartbeat Message The Heartbeat (HB) Message is used for one ForCES element (FE or CE) to asynchronously notify one or more other ForCES elements in the same ForCES NE on its liveness, while the FE protocol LFB attribute ,the Heartbeat policy and parameters, defined in Section 6.2.1 defines how the Heartbeat Message should be used by CE or FE. This section only defines the Heartbeat Message data format. A little different from other protocol messages, a Heartbeat message is only composed of a common header, while the message body is always left empty. Detailed description of the message is as below. Message Transfer Direction: FE to CE, or CE to FE Message Header: The Message Type in the message header is set to MessageType = 'Heartbeat'. The ACK flag in the header can be set to 'NoACK' or 'AlwyasACK'. when set to 'AlwaysACK', the HB Message is always expecitng a response from its receiver. For a HB Message, we define that its response still has the data format as a normal HB Message that is sent back by the original HB Message receiver. For a HB Message acting as a response, its ACK flag should alwways be set to 'NoACK', meaning no further response should be given for the message. The default behavior for the ACK flag is set to no response for the HB Message. This happens when the ACK flag is set to values other than 'NoACK' and 'AlwaysACK'. The correlator field in the messge header MUST be set if a response is expected, so that a receiver can correlate the response correctly. The correlator field can be ignored if no response is expected. Also note that by the current Heartbeat policies defined' in Section 6.2.1, only CE can possibly send a HB Message with a response request. Message Body: The message body is empty for the Heartbeat Message. ----- Original Message ----- From: "Weiming Wang" > I don't know why the attached file does not appear. just resend it. > > ----- Original Message ----- > From: "Weiming Wang" > > > Jamal, > > > > attached is the update I tried for the HB message. Pls feel free to modify it. > > > > Thank, > > Weiming > > > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > To: > > Sent: Thursday, October 13, 2005 8:34 PM > > Subject: updated text - rest of sec6 > > > > > > > > > > More text for review from sec 6.3 to end of section 6. This section is > > > updated just to reflect the grammar updates - so nothing controversial. > > > The sections that needs to be stared at the most is the config message > > > followed by the table at the end (which needs to be validated against > > > each message). I have added an extra column to the table to be more > > > reflective of the grammar. > > > > > > The two core LFBs and the heartbeat section remain outstanding in this > > > section. If i dont hear from Weiming by end of day, I will attack the HB > > > message followed by the core LFBS. We are getting there ... > > > > > > > > > cheers, > > > jamal > > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 11:57:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5Sx-0007ij-Fu for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 11:57:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25452 for ; Thu, 13 Oct 2005 11:57:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ5dQ-0007c5-VB for forces-archive@IETF.ORG; Thu, 13 Oct 2005 12:08:53 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0110E5E0@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 11:57:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87931934 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 11:57:38 -0400 Received: from 192.11.226.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 11:57:38 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j9DFvW9j029471; Thu, 13 Oct 2005 10:57:32 -0500 (CDT) Received: from lucent.com (topgun.dnrc.bell-labs.com [135.180.160.129]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j9DFvVE08588; Thu, 13 Oct 2005 11:57:31 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E07029224@orsmsx408> Content-Type: multipart/alternative; boundary="------------050102040202030809090509" Approved-By: "Furquan A. Ansari" Message-ID: <434E8528.20006@lucent.com> Date: Thu, 13 Oct 2005 12:02:48 -0400 Reply-To: "Furquan A. Ansari" Sender: Forwarding and Control Element Separation From: "Furquan A. Ansari" Organization: Lucent Technologies Inc. Subject: Re: updated text on HA section Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.5 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd --------------050102040202030809090509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Hormuzd/all, Haven't been closely following the discussion recently on the mailing list since I was quite busy with a few things. However, after quickly going through the HA support section, I would be hesitant to put this in the current draft. I feel that the HA situation is more complicated than spelled out here and in fact could/should come as a separate draft in its own right. Here are a few things that complicate the situation: 1) In an NE with multiple CEs (Active and backups) and FEs, it is mentioned that a communication failure between a CE and an FE - due to either link reasons or CE failure - it would trigger the FE to switch over to the backup (using PL/TML) CE. This can lead to a "very bad situation" in case of loss of communication due to link failure. We do not want to be in a situation where only "one" of the FEs is now being managed/controlled by the backup CE while all other FEs are being controlled by the active CE (since the active CE is still functional and the loss of association between the active CE and one of the FEs in question occured either due to link failure or TML channel failure etc.). This not only destroys the notion of the having a single active CE within an NE (since we now have the original active CE still controlling the other FEs along with the backup CE now acting as an active CE for "one" FE), but making the whole collection of CE and FEs function together as a single NE would be close to impossible, since higher layer applications such as routing protocols etc. will now have to be run from both the CEs. So, essentially, I would say that there are a few choices we have: 1) If one of the FEs is switching over to the backup CE, then all other FEs will have to switch over the backup CE as well - Don't like this choice very much, because this would cause great disruption at the network level since applications will have to be restarted at the backup (e.g. routing protocols) 2) When a majority/all of the FEs are reporting loss of the connectivity to the active CE (reported to the backup CE), only then should the backup CE take over the functionality as the active CE. - Better choice than before, but still not the best one - since what happens to the FEs that are not reachable by the active CE? How do we establish control over them since the communication is lost? Should the backup CE somehow help this FE in trying to establish the connection/association back to the active CE? I can go on with many scenarios, but will stop here for now. Regards, Khosravi, Hormuzd M wrote: > The text is attached as per the protocol team discussions. > > regards > Hormuzd > > >------------------------------------------------------------------------ > >8. High Availability Support > >The ForCES protocol provides mechanisms for CE redundancy and failover, >in order to support High Availability as defined in [RFC3654]. FE redundancy >and FE to FE interaction is currently out of scope of this draft. There >can be multiple redundant CEs and FEs in a ForCES NE. However, at any >time there can only be one Primary CE controlling the FEs and there can >be multiple secondary CEs. The FE and the CE PL are aware of the primary >and secondary CEs. This information (primary, secondary CEs) is configured >in the FE, CE PLs during pre-association by FEM, CEM respectively. Only >the primary CE sends Control messages to the FEs. > >There are 2 modes of HA defined in the ForCES protocol, Report Primary Mode >and Report All Mode. The Report Primary Mode is the default mode of the protocol, >in which the FEs only associate with one CE (primary) at a time. The Report All >mode is for future study and not part of the current protocol version. In this mode, >the FE would establish association with multiple CEs (primary & secondary) and >report events, packets, Heart Beats to all the CEs. However, only the primary CE >would configure/control the FE in this mode as well. This helps with keeping state >between CEs synchronized, although it does not guarantee synchronization. > >The HA Modes are configured during Association setup phase, currently only Report >Primary Mode is configured. A CE-to-CE synchronization protocol will be needed >to support fast failover, however this will not be defined by the ForCES protocol. > >During a communication failure between the FE and CE (which is caused due to CE >or link reasons, i.e. not FE related), the TML on the FE will trigger the FE PL >regarding this failure. This can also be detected using the HB messages between >FEs and CEs. The communication failure (detected via either of the two means >described before) is considered as a loss of association between the CE and >corresponding FE and the FE PL must establish association with the secondary CE at >this point. During this phase, if the original primary CE comes alive and starts >sending any commands to the FE, the FE should ignore those messages and send an >Event to all CEs indicating its change in Primary CE. Thus the FE only has one >primary CE at a time. > >An explicit message (Config message setting Primary CE attribute in ForCES Protocol >object) from the primary CE, can also be used to change the Primary CE for an FE >during normal protocol operation. > > -- Furquan Ansari Bell Labs Research Ph : 732-949-5249 Holmdel, NJ Fax: 732-949-4556 --------------050102040202030809090509 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Hormuzd/all,
    Haven't been closely following the discussion recently  on the mailing list since I was quite
busy with a few things. However, after quickly going through the HA support section, I would be
hesitant to put this in the current draft. I feel that the HA situation is more complicated than
spelled out here and in fact could/should come as a separate draft in its own right.

Here are a few things that complicate the situation:
1) In an NE with multiple CEs (Active and backups) and FEs, it is mentioned that a communication
failure between a CE and an FE - due to either link reasons or CE failure - it would trigger the FE to
switch over to the backup (using PL/TML) CE. This can lead to a "very bad situation" in case of loss
of communication due to link failure. We do not want to be in a situation where only "one" of the FEs is
now being managed/controlled by the backup CE while all other FEs are being controlled by the active
CE (since the active CE is still functional and the loss of association between the active CE and one of
the FEs in question occured either due to link failure or TML channel failure etc.). This not only
destroys the notion of the having a single active CE within an NE (since we now have the original active
CE still controlling the other FEs along with the backup CE now acting as an active CE for "one" FE), but
making the whole collection of CE and FEs function together as a single NE would be close to impossible,
since higher layer applications such as routing protocols etc. will now have to be run from both the CEs.

So, essentially, I would say that there are a few choices we have:
1) If one of the FEs is switching over to the backup CE, then all other FEs will have to switch over the
backup CE as well
    - Don't like this choice very much, because this would cause great disruption at the network level since applications will have to be restarted at the backup (e.g. routing protocols)
2) When a majority/all of the FEs are reporting loss of the connectivity to the active CE (reported to the backup CE), only then should the backup CE take over the functionality as the active CE.
   - Better choice than before, but still not the best one - since what happens to the FEs that are not
reachable by the active CE? How do we establish control over them since the communication is lost?
Should the backup CE somehow help this FE in trying to establish the connection/association back to the active CE?

I can go on with many scenarios, but will stop here for now.

Regards,


Khosravi, Hormuzd M wrote:
The text is attached as per the protocol team discussions.
 
regards
Hormuzd
 

8. High Availability Support

The ForCES protocol provides mechanisms for CE redundancy and failover, 
in order to support High Availability as defined in [RFC3654].  FE redundancy 
and FE to FE interaction is currently out of scope of this draft.  There 
can be multiple redundant CEs and FEs in a ForCES NE.  However, at any 
time there can only be one Primary CE controlling the FEs and there can 
be multiple secondary CEs.  The FE and the CE PL are aware of the primary 
and secondary CEs.  This information (primary, secondary CEs) is configured 
in the FE, CE PLs during pre-association by FEM, CEM respectively.  Only 
the primary CE sends Control messages to the FEs. 

There are 2 modes of HA defined in the ForCES protocol, Report Primary Mode 
and Report All Mode. The Report Primary Mode is the default mode of the protocol, 
in which the FEs only associate with one CE (primary) at a time. The Report All 
mode is for future study and not part of the current protocol version. In this mode, 
the FE would establish association with multiple CEs (primary & secondary) and 
report events, packets, Heart Beats to all the CEs. However, only the primary CE 
would configure/control the FE in this mode as well. This helps with keeping state 
between CEs synchronized, although it does not guarantee synchronization. 

The HA Modes are configured during Association setup phase, currently only Report 
Primary Mode is configured.  A CE-to-CE synchronization protocol will be needed 
to support fast failover, however this will not be defined by the ForCES protocol.

During a communication failure between the FE and CE (which is caused due to CE 
or link reasons, i.e. not FE related), the TML on the FE will trigger the FE PL 
regarding this failure.  This can also be detected using the HB messages between 
FEs and CEs.  The communication failure (detected via either of the two means 
described before) is considered as a loss of association between the CE and 
corresponding FE and the FE PL must establish association with the secondary CE at 
this point.  During this phase, if the original primary CE comes alive and starts 
sending any commands to the FE, the FE should ignore those messages and send an 
Event to all CEs indicating its change in Primary CE.  Thus the FE only has one 
primary CE at a time.

An explicit message (Config message setting Primary CE attribute in ForCES Protocol 
object) from the primary CE, can also be used to change the Primary CE for an FE 
during normal protocol operation.
  

-- 
Furquan Ansari
Bell Labs Research			Ph : 732-949-5249
Holmdel, NJ				Fax: 732-949-4556

--------------050102040202030809090509-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 13:57:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7KU-0002gx-QU for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 13:57:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02277 for ; Thu, 13 Oct 2005 13:57:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ7V2-0002VT-Mc for forces-archive@IETF.ORG; Thu, 13 Oct 2005 14:08:18 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0110EA74@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 13:57:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87940535 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 13:57:18 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 13:57:17 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9DHuEXK032617; Thu, 13 Oct 2005 10:56:14 -0700 (PDT) References: <1129206881.6412.32.camel@localhost.localdomain> <002001c5d005$a402fbc0$1f12fea9@wwm1> <006901c5d006$831c0540$1f12fea9@wwm1> <007501c5d007$9ee23320$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129226205.6282.19.camel@localhost.localdomain> Date: Thu, 13 Oct 2005 13:56:45 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated text - rest of sec6 Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <007501c5d007$9ee23320$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Thanks for the text Weiming. I have updated to read as follows: --- 6.9. Heartbeat Message The Heartbeat (HB) Message is used for one ForCES element (FE or CE) to asynchronously notify one or more other ForCES elements in the same ForCES NE on its liveness. A Heartbeat Message is sent by a ForCES element periodically. The parameterization and policy definition for heartbeats for an FE is managed as attributes of the FE protocol LFB, and can be set by CE via a config message. The Heartbeat message is a little different from other protocol messages in that it is only composed of a common header, with the message body left empty. Detailed description of the message is as below. Message Transfer Direction: FE to CE, or CE to FE Message Header: The Message Type in the message header is set to MessageType = 'Heartbeat'. Section 3.3.2 describes the HB mechanisms used. The ACK flag in the header can be set to 'NoACK' or 'AlwaysACK' when the HB is sent. When set to 'AlwaysACK', the HB Message sender is always expecting a response from its receiver. When a response is sent it is always an echo of the original message with reversed IDs and the ACK information set to 'NoACK'. When not soliciting for response(default behavior), the ACK flag is set to 'NoACK' The correlator field in the HB message header must be set accordingly when a response is expected so that a receiver can correlate the response correctly. The correlator field can be ignored if no response is expected. Also note that by virtue of Heartbeat policies defined in Section 6.2.1 only CE can send a HB Message with a response request. Message Body: The message body is empty for the Heartbeat Message. ------------- I have also introduced a new section 3.3.2 with the following text: ---------------- 3.3.2. Heartbeating Mechanism Hearbeats between FEs and CEs are traffic sensitive. A HB is sent only if no PL traffic is sent between the CE and FE within a configured interval. This has the effect of reducing the amount of HB traffic in the case of busy PL periods. A HB can be sourced by either the CE or FE. When sourced by the CE, a response can be requested (similar to the ICMP ping protocol). The FE can only generate HBs in the case of being configured to do so by the CE. Refer to Section 3.3.3 and Section 6.9 for details. --------------- Please comment cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 14:07:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ7UP-0006Dn-Ry for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 14:07:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03068 for ; Thu, 13 Oct 2005 14:07:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ7ey-0002sU-Eo for forces-archive@IETF.ORG; Thu, 13 Oct 2005 14:18:32 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0110E9D1@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 14:07:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87941454 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 14:07:35 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 14:07:34 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9DI6oXK032712; Thu, 13 Oct 2005 11:06:51 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E07029224@orsmsx408> <434E8528.20006@lucent.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129226843.6282.32.camel@localhost.localdomain> Date: Thu, 13 Oct 2005 14:07:23 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated text on HA section Comments: To: "Furquan A. Ansari" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <434E8528.20006@lucent.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit On Thu, 2005-13-10 at 12:02 -0400, Furquan A. Ansari wrote: > Hello Hormuzd/all, > Haven't been closely following the discussion recently on the > mailing list since I was quite > busy with a few things. However, after quickly going through the HA > support section, I would be > hesitant to put this in the current draft. I feel that the HA > situation is more complicated than > spelled out here and in fact could/should come as a separate draft in > its own right. > > Here are a few things that complicate the situation: > 1) In an NE with multiple CEs (Active and backups) and FEs, it is > mentioned that a communication > failure between a CE and an FE - due to either link reasons or CE > failure - it would trigger the FE to > switch over to the backup (using PL/TML) CE. This can lead to a "very > bad situation" in case of loss > of communication due to link failure. We do not want to be in a > situation where only "one" of the FEs is > now being managed/controlled by the backup CE while all other FEs are > being controlled by the active > CE (since the active CE is still functional and the loss of > association between the active CE and one of > the FEs in question occured either due to link failure or TML channel > failure etc.). This not only > destroys the notion of the having a single active CE within an NE > (since we now have the original active > CE still controlling the other FEs along with the backup CE now acting > as an active CE for "one" FE), but > making the whole collection of CE and FEs function together as a > single NE would be close to impossible, > since higher layer applications such as routing protocols etc. will > now have to be run from both the CEs. > Hrm. Reading this and factoring in that text on multicast IDs is missing at the moment makes it imperative that such text gets added. Hormuzd please update the text. Lets take the case of the CE first (the same concept would apply to the FE, so ignore it for now): If we have a CEID which is from a group that is multicast, then a link loss does not necessarily translate to a TML loss. In the case of a TCP TML for example, a socket getting an eof is when you decided your association is lost and therefore require a failover. A physical interface loss would be sufficiently dealt with by other mechanisms (VRRP if you are using IP without affecting the socket/TML level. In other words it is fair to say that link level loss does not equate to a failover, no? Now if you do use a multicast CEID: - the FE PL does not distinguish which CE failed; that is a TML responsibility. Only when all CEs that map to a multicast CEID are lost does the TML declare that the association is lost. - in an active/backup setup, you MAY need to have things like routing protocols running on both and synchronized or booted on failover(depending on your scheme). But this is outside our scope. - in an active/active setup(which is really outside our scope again), the FE PL should be able to receive messages from N CEs as long as they are mapped to the multicast CEID, no? > So, essentially, I would say that there are a few choices we have: > 1) If one of the FEs is switching over to the backup CE, then all > other FEs will have to switch over the > backup CE as well > - Don't like this choice very much, because this would cause great > disruption at the network level since applications will have to be > restarted at the backup (e.g. routing protocols) Refer to my comment above. > 2) When a majority/all of the FEs are reporting loss of the > connectivity to the active CE (reported to the backup CE), only then > should the backup CE take over the functionality as the active CE. > - Better choice than before, but still not the best one - since > what happens to the FEs that are not > reachable by the active CE? How do we establish control over them > since the communication is lost? > Should the backup CE somehow help this FE in trying to establish the > connection/association back to the active CE? > > I can go on with many scenarios, but will stop here for now. > Please review the case of multicast CEID and see if it resolves your issues. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 15:10:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ8Sz-00076O-KG for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 15:10:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05718 for ; Thu, 13 Oct 2005 15:10:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ8dU-0004Kg-RQ for forces-archive@IETF.ORG; Thu, 13 Oct 2005 15:21:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0110EB90@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 15:10:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87945504 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 15:10:06 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 15:10:06 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9DJA5Fc016471; Thu, 13 Oct 2005 19:10:05 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9DJ9kST027797; Thu, 13 Oct 2005 19:10:03 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101312082430478 ; Thu, 13 Oct 2005 12:08:26 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Oct 2005 12:07:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] ForCES Intra-NE routing mechanism Thread-Index: AcXP9mJsaeA02TboSx2Qiny4Io4vUwAMkaAQ X-OriginalArrivalTime: 13 Oct 2005 19:07:26.0087 (UTC) FILETIME=[59547170:01C5D029] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0705D5CA@orsmsx408> Date: Thu, 13 Oct 2005 12:07:25 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES Intra-NE routing mechanism Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable I think this could be a good Informational RFC at the least.=20 I am not sure if this is what Xiaoyi Guo has in mind, but I wouldn't have any objection to having an informational rfc on this. Xiaoyi Guo, you should look at the Topology draft as well, there is some overlap here. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern 2) I don't see the value in creating a new kind of forwarding table. For=20 each FE, the forwarding table it is given ought to translate an IP prefix=20 into a next hop, and the next hop into an egress port. You seem to be=20 trying to add a third layer of mapping. The benefit I can see for such a=20 thing might be that it could reduce slightly the differences in the tables=20 across the FEs. However, I would be really unhappy at mandating such an=20 architecture. Yours, Joel At 05:58 AM 10/13/2005, Xiaoyi Guo wrote: >All, > >I'm currently putting a draft of the ForCES Intra-NE routing mechaniam, >and will submit it by Thusday.Below are the major points, please comment. > >About ForCES Intra-NE routing mechanism > ----------------- > | CE | > ----------------- > A ^ B ^ C ^ > / | \ > / A v \ > / ------- B \ > / +->| FE3 |<-+ \ > / |C | | | \ > A v | ------- | v A > -------B | |E ------- > | FE1 |<-+ +->| FE2 | > | |<--------------->| | > ------- C D ------- > E ^ D| C ^ | B > | | | | > | v | v > >When a packet comes in FE1 port E and it want to forwaring to FE2 port B, >it must across the Intra-NE FEs. > >There has two ways to generate the routing paths : >1, static configuration from FEM / CEM , >2, dynamic generated by system . > >Obviously the first method is not a good choice , so we focus on the=20 >latter one. >We aleardy know the full topology from the CE topology table , this is=20 >designed and generated by >Intra-NE topology discovery mechanism. > >But this topology table need to caculate and generate to the CE's=20 >Intra-routing table. >For example , in this Figure , there exist two path from FE1 to FE2, so we=20 >must use some policy >to select a better one which the cost is smaller. The method maybe like >the OSPF SPF tree algorithm >or other similar algorithm. > >See the CE topology table >---------------------------------------------- > > FE1 B FE2 D > FE2 E FE3 D > FE1 B FE2 C > >We will add a Intra-FIB in each FE , this table is distributed by master CE: >i will add some structure such as nexthop(port) , nextNode(FE), so it=20 >looks like a table as below > >FE1 IFIB (part) >----------------------------------------------------------------------- ------------------------- > > FE1 B FE3 D FE2=20 > D > > FE2 IFIB (part) >----------------------------------------------------------------------- ------------------------ > > FE2 E FE3 D FE3=20 > D > >When the packet arrived at FE1 , Then FE1 find the Nexthop by searching=20 >FIB , >and then searching IFIB , FE1 will know the routing path is from FE1 to >FE3 then to FE2. In FE3 , >only search the IFIB, the packet forward to FE2 with the correct path , >then FE2 will forward it out the NE . > >This two table searching mechanism is a bit similar to such as MPLS or=20 >other VPN label pursh/pop action. > >The advantages as below : >1, The Intra-NE full topylogy need not known by each FE. >2, Intra-FE do not need the outer routing information. > > >Best Regards > >Xiaoyi Guo >------------------------------------------------ >Huawei Technologies. >No. 3 Xinxi Rd., Shang-Di Information Industry Base, >Hai-Dian District Beijing, P.R. China 100085 >Tel: +86-10-8288-2290 >Fax: +86-10-8288-2770 ><mailto:xiaotian@huawei.com> > >------------------------------------------ From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 18:50:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBuQ-0008OJ-GU for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 18:50:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25031 for ; Thu, 13 Oct 2005 18:50:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQC51-0004IP-17 for forces-archive@IETF.ORG; Thu, 13 Oct 2005 19:01:44 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0110EDE5@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 18:50:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87958649 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 18:50:24 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 18:50:23 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9DMoIqO009339; Thu, 13 Oct 2005 22:50:18 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9DMoGJJ022883; Thu, 13 Oct 2005 22:50:18 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101315501822507 ; Thu, 13 Oct 2005 15:50:18 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Oct 2005 15:50:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D048.7B19F97E" Thread-Topic: [FORCES] updated text on HA section Thread-Index: AcXQDuSbIbuygABqSCOjxoudLMBGzQAORohg X-OriginalArrivalTime: 13 Oct 2005 22:50:17.0780 (UTC) FILETIME=[7B7ADF40:01C5D048] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E07096175@orsmsx408> Date: Thu, 13 Oct 2005 15:50:16 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: updated text on HA section Comments: To: "Furquan A. Ansari" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.6 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D048.7B19F97E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good point Furquan. =20 I am not sure we can solve this in an elegant way or any way without some sort of CE-to-CE communication mechanism. I'll send out the text with the addition of the CE Multicast ID case as Jamal suggested, but that might not be directly applicable for this case. =20 We can definitely mention this as an issue in the draft and propose some solutions based on CE-to-CE mechanisms, which are not yet defined. =20 Thanks for reviewing this! Hormuzd ________________________________ From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Furquan A. Ansari Sent: Thursday, October 13, 2005 9:03 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] updated text on HA section Hello Hormuzd/all, Haven't been closely following the discussion recently on the mailing list since I was quite=20 busy with a few things. However, after quickly going through the HA support section, I would be hesitant to put this in the current draft. I feel that the HA situation is more complicated than spelled out here and in fact could/should come as a separate draft in its own right. Here are a few things that complicate the situation: 1) In an NE with multiple CEs (Active and backups) and FEs, it is mentioned that a communication failure between a CE and an FE - due to either link reasons or CE failure - it would trigger the FE to switch over to the backup (using PL/TML) CE. This can lead to a "very bad situation" in case of loss of communication due to link failure. We do not want to be in a situation where only "one" of the FEs is now being managed/controlled by the backup CE while all other FEs are being controlled by the active CE (since the active CE is still functional and the loss of association between the active CE and one of=20 the FEs in question occured either due to link failure or TML channel failure etc.). This not only destroys the notion of the having a single active CE within an NE (since we now have the original active CE still controlling the other FEs along with the backup CE now acting as an active CE for "one" FE), but making the whole collection of CE and FEs function together as a single NE would be close to impossible, since higher layer applications such as routing protocols etc. will now have to be run from both the CEs. So, essentially, I would say that there are a few choices we have: 1) If one of the FEs is switching over to the backup CE, then all other FEs will have to switch over the backup CE as well - Don't like this choice very much, because this would cause great disruption at the network level since applications will have to be restarted at the backup (e.g. routing protocols) 2) When a majority/all of the FEs are reporting loss of the connectivity to the active CE (reported to the backup CE), only then should the backup CE take over the functionality as the active CE. - Better choice than before, but still not the best one - since what happens to the FEs that are not reachable by the active CE? How do we establish control over them since the communication is lost? Should the backup CE somehow help this FE in trying to establish the connection/association back to the active CE? I can go on with many scenarios, but will stop here for now. Regards, Khosravi, Hormuzd M wrote: The text is attached as per the protocol team discussions. =20 regards Hormuzd =20 =09 ________________________________ 8. High Availability Support =09 The ForCES protocol provides mechanisms for CE redundancy and failover,=20 in order to support High Availability as defined in [RFC3654]. FE redundancy=20 and FE to FE interaction is currently out of scope of this draft. There=20 can be multiple redundant CEs and FEs in a ForCES NE. However, at any=20 time there can only be one Primary CE controlling the FEs and there can=20 be multiple secondary CEs. The FE and the CE PL are aware of the primary=20 and secondary CEs. This information (primary, secondary CEs) is configured=20 in the FE, CE PLs during pre-association by FEM, CEM respectively. Only=20 the primary CE sends Control messages to the FEs.=20 =09 There are 2 modes of HA defined in the ForCES protocol, Report Primary Mode=20 and Report All Mode. The Report Primary Mode is the default mode of the protocol,=20 in which the FEs only associate with one CE (primary) at a time. The Report All=20 mode is for future study and not part of the current protocol version. In this mode,=20 the FE would establish association with multiple CEs (primary & secondary) and=20 report events, packets, Heart Beats to all the CEs. However, only the primary CE=20 would configure/control the FE in this mode as well. This helps with keeping state=20 between CEs synchronized, although it does not guarantee synchronization.=20 =09 The HA Modes are configured during Association setup phase, currently only Report=20 Primary Mode is configured. A CE-to-CE synchronization protocol will be needed=20 to support fast failover, however this will not be defined by the ForCES protocol. =09 During a communication failure between the FE and CE (which is caused due to CE=20 or link reasons, i.e. not FE related), the TML on the FE will trigger the FE PL=20 regarding this failure. This can also be detected using the HB messages between=20 FEs and CEs. The communication failure (detected via either of the two means=20 described before) is considered as a loss of association between the CE and=20 corresponding FE and the FE PL must establish association with the secondary CE at=20 this point. During this phase, if the original primary CE comes alive and starts=20 sending any commands to the FE, the FE should ignore those messages and send an=20 Event to all CEs indicating its change in Primary CE. Thus the FE only has one=20 primary CE at a time. =09 An explicit message (Config message setting Primary CE attribute in ForCES Protocol=20 object) from the primary CE, can also be used to change the Primary CE for an FE=20 during normal protocol operation. =20 --=20 Furquan Ansari Bell Labs Research Ph : 732-949-5249 Holmdel, NJ Fax: 732-949-4556 ------_=_NextPart_001_01C5D048.7B19F97E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Good point Furquan.
 
I am not sure we can solve this in an elegant = way or any=20 way without some sort of CE-to-CE communication = mechanism.
I'll send out the text with the addition of the = CE=20 Multicast ID case as Jamal suggested, but that might not be directly = applicable=20 for this case.
 
We can definitely mention this as an issue in = the draft and=20 propose some solutions based on CE-to-CE mechanisms, which are not yet=20 defined.
 
Thanks for reviewing this!
Hormuzd

From: Forwarding and Control Element = Separation=20 [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Furquan A.=20 Ansari
Sent: Thursday, October 13, 2005 9:03 AM
To:=20 FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] updated text = on HA=20 section

Hello Hormuzd/all,
    Haven't been closely = following the discussion recently  on the mailing list since I was = quite=20
busy with a few things. However, after quickly going through the HA = support=20 section, I would be
hesitant to put this in the current draft. I feel = that=20 the HA situation is more complicated than
spelled out here and in = fact=20 could/should come as a separate draft in its own right.

Here are = a few=20 things that complicate the situation:
1) In an NE with multiple CEs = (Active=20 and backups) and FEs, it is mentioned that a communication
failure = between a=20 CE and an FE - due to either link reasons or CE failure - it would = trigger the=20 FE to
switch over to the backup (using PL/TML) CE. This can lead to a = "very=20 bad situation" in case of loss
of communication due to link failure. = We do=20 not want to be in a situation where only "one" of the FEs is
now = being=20 managed/controlled by the backup CE while all other FEs are being = controlled by=20 the active
CE (since the active CE is still functional and the loss = of=20 association between the active CE and one of
the FEs in question = occured=20 either due to link failure or TML channel failure etc.). This not=20 only
destroys the notion of the having a single active CE within an = NE (since=20 we now have the original active
CE still controlling the other FEs = along with=20 the backup CE now acting as an active CE for "one" FE), but
making = the whole=20 collection of CE and FEs function together as a single NE would be close = to=20 impossible,
since higher layer applications such as routing protocols = etc.=20 will now have to be run from both the CEs.

So, essentially, I = would say=20 that there are a few choices we have:
1) If one of the FEs is = switching over=20 to the backup CE, then all other FEs will have to switch over = the
backup CE=20 as well
    - Don't like this choice very much, = because this=20 would cause great disruption at the network level since applications = will have=20 to be restarted at the backup (e.g. routing protocols)
2) When a = majority/all=20 of the FEs are reporting loss of the connectivity to the active CE = (reported to=20 the backup CE), only then should the backup CE take over the = functionality as=20 the active CE.
   - Better choice than before, but still = not the=20 best one - since what happens to the FEs that are not
reachable by = the active=20 CE? How do we establish control over them since the communication is=20 lost?
Should the backup CE somehow help this FE in trying to = establish the=20 connection/association back to the active CE?

I can go on with = many=20 scenarios, but will stop here for = now.

Regards,


Khosravi,=20 Hormuzd M wrote:
The = text is=20 attached as per the protocol = team discussions.
 
regards
Hormuzd
 

8. High Availability Support

The ForCES protocol provides mechanisms for CE redundancy and failover,=20
in order to support High Availability as defined in [RFC3654].  FE =
redundancy=20
and FE to FE interaction is currently out of scope of this draft.  There =

can be multiple redundant CEs and FEs in a ForCES NE.  However, at any=20
time there can only be one Primary CE controlling the FEs and there can=20
be multiple secondary CEs.  The FE and the CE PL are aware of the =
primary=20
and secondary CEs.  This information (primary, secondary CEs) is =
configured=20
in the FE, CE PLs during pre-association by FEM, CEM respectively.  Only =

the primary CE sends Control messages to the FEs.=20

There are 2 modes of HA defined in the ForCES protocol, Report Primary =
Mode=20
and Report All Mode. The Report Primary Mode is the default mode of the =
protocol,=20
in which the FEs only associate with one CE (primary) at a time. The =
Report All=20
mode is for future study and not part of the current protocol version. =
In this mode,=20
the FE would establish association with multiple CEs (primary & =
secondary) and=20
report events, packets, Heart Beats to all the CEs. However, only the =
primary CE=20
would configure/control the FE in this mode as well. This helps with =
keeping state=20
between CEs synchronized, although it does not guarantee =
synchronization.=20

The HA Modes are configured during Association setup phase, currently =
only Report=20
Primary Mode is configured.  A CE-to-CE synchronization protocol will be =
needed=20
to support fast failover, however this will not be defined by the ForCES =
protocol.

During a communication failure between the FE and CE (which is caused =
due to CE=20
or link reasons, i.e. not FE related), the TML on the FE will trigger =
the FE PL=20
regarding this failure.  This can also be detected using the HB messages =
between=20
FEs and CEs.  The communication failure (detected via either of the two =
means=20
described before) is considered as a loss of association between the CE =
and=20
corresponding FE and the FE PL must establish association with the =
secondary CE at=20
this point.  During this phase, if the original primary CE comes alive =
and starts=20
sending any commands to the FE, the FE should ignore those messages and =
send an=20
Event to all CEs indicating its change in Primary CE.  Thus the FE only =
has one=20
primary CE at a time.

An explicit message (Config message setting Primary CE attribute in =
ForCES Protocol=20
object) from the primary CE, can also be used to change the Primary CE =
for an FE=20
during normal protocol operation.
  

--=20
Furquan Ansari
Bell Labs Research			Ph : 732-949-5249
Holmdel, NJ				Fax: 732-949-4556

------_=_NextPart_001_01C5D048.7B19F97E-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 21:42:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQEap-00051D-JR for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 21:42:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09029 for ; Thu, 13 Oct 2005 21:42:37 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQEWK-00026J-BL for forces-archive@IETF.ORG; Thu, 13 Oct 2005 21:38:10 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0110F131@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 21:27:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87966670 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 21:27:02 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 21:27:00 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Fri, 14 Oct 2005 10:07:22 +0800 (CST) References: <1129206881.6412.32.camel@localhost.localdomain> <002001c5d005$a402fbc0$1f12fea9@wwm1> <006901c5d006$831c0540$1f12fea9@wwm1> <007501c5d007$9ee23320$1f12fea9@wwm1> <1129226205.6282.19.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <002f01c5d05e$656c5970$1f12fea9@wwm1> Date: Fri, 14 Oct 2005 09:27:08 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: updated text - rest of sec6 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Jamal, that looks good to me. Only one thing is, maybe it is better to mention the Section 6.2.1 Heartbeat policy attribute in Section 3.3.2( Heartbeating Mechanism) as well. cheers, weiming ----- Original Message ----- From: "Jamal Hadi Salim" > Thanks for the text Weiming. I have updated to read as follows: > > > --- > > 6.9. Heartbeat Message > > The Heartbeat (HB) Message is used for one ForCES element (FE or CE) > to asynchronously notify one or more other ForCES elements in the > same ForCES NE on its liveness. > > A Heartbeat Message is sent by a ForCES element periodically. The > parameterization and policy definition for heartbeats for an FE is > managed as attributes of the FE protocol LFB, and can be set by CE > via a config message. The Heartbeat message is a little different > from other protocol messages in that it is only composed of a common > header, with the message body left empty. Detailed description of > the message is as below. > > Message Transfer Direction: > FE to CE, or CE to FE > > Message Header: > The Message Type in the message header is set to MessageType = > 'Heartbeat'. Section 3.3.2 describes the HB mechanisms used. > The ACK flag in the header can be set to 'NoACK' or 'AlwaysACK' > when the HB is sent. When set to 'AlwaysACK', the HB Message > sender is always expecting a response from its receiver. When a > response is sent it is always an echo of the original message > with reversed IDs and the ACK information set to 'NoACK'. When > not soliciting for response(default behavior), the ACK flag is > set to 'NoACK' The correlator field in the HB message header must > > be set accordingly when a response is expected so that a receiver > can correlate the response correctly. The correlator field can > be ignored if no response is expected. Also note that by virtue > of Heartbeat policies defined in Section 6.2.1 only CE can send a > HB Message with a response request. > > Message Body: > The message body is empty for the Heartbeat Message. > ------------- > > > I have also introduced a new section 3.3.2 with the following text: > > ---------------- > 3.3.2. Heartbeating Mechanism > > Hearbeats between FEs and CEs are traffic sensitive. A HB is sent > only if no PL traffic is sent between the CE and FE within a > configured interval. This has the effect of reducing the amount of > HB traffic in the case of busy PL periods. > > A HB can be sourced by either the CE or FE. When sourced by the CE, > a response can be requested (similar to the ICMP ping protocol). The > FE can only generate HBs in the case of being configured to do so by > the CE. Refer to Section 3.3.3 and Section 6.9 for details. > --------------- > > Please comment > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 22:13:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQF48-0006gy-6V for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 22:13:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10241 for ; Thu, 13 Oct 2005 22:12:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQFEh-0003Kb-9i for forces-archive@IETF.ORG; Thu, 13 Oct 2005 22:23:59 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0110F105@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 22:12:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87968693 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 22:12:53 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 22:12:53 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9E2C6XK035958; Thu, 13 Oct 2005 19:12:07 -0700 (PDT) References: <1129206881.6412.32.camel@localhost.localdomain> <002001c5d005$a402fbc0$1f12fea9@wwm1> <006901c5d006$831c0540$1f12fea9@wwm1> <007501c5d007$9ee23320$1f12fea9@wwm1> <1129226205.6282.19.camel@localhost.localdomain> <002f01c5d05e$656c5970$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129255964.7115.16.camel@localhost.localdomain> Date: Thu, 13 Oct 2005 22:12:44 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated text - rest of sec6 Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <002f01c5d05e$656c5970$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit On Fri, 2005-14-10 at 09:27 +0800, Weiming Wang wrote: > Jamal, that looks good to me. > > Only one thing is, maybe it is better to mention the Section 6.2.1 Heartbeat > policy attribute in Section 3.3.2( Heartbeating Mechanism) as well. > Weiming, I actually meant to have 6.2.1 instead of 3.3.3 or do you mean i should add 6.2.1 in addition ? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 22:18:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQF9G-00089C-9D for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 22:18:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10375 for ; Thu, 13 Oct 2005 22:18:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQFJt-0003Pw-E8 for forces-archive@IETF.ORG; Thu, 13 Oct 2005 22:29:17 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0110EF8D@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 22:18:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87968914 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 22:18:15 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 22:18:15 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9E2HZXK035983 for ; Thu, 13 Oct 2005 19:17:35 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-JCSh3hFah0fmtnZcjomE" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129256293.7115.19.camel@localhost.localdomain> Date: Thu, 13 Oct 2005 22:18:13 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: sec 6.2 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba --=-JCSh3hFah0fmtnZcjomE Content-Type: text/plain Content-Transfer-Encoding: 7bit This section is very shaky at the moment. Weiming, is this the text we settled for FEPO? If yes, I will proceed to fix the xml. cheers, jamal --=-JCSh3hFah0fmtnZcjomE Content-Disposition: attachment; filename=sec6.2.txt Content-Type: text/plain; name=sec6.2.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 6.2. Core ForCES LFBs There are two LFBs that are used to control the operation of the ForCES protocol and to interact with FEs and CEs: FE Protocol LFB FE Object LFB Although these LFBs have the same form and interface as other LFBs, they are special in many respects: they have fixed well-known LFB Class and Instance IDs. They are statically defined (no dynamic instantiation allowed) and their status cannot be changed by the protocol: any operation to change the state of such LFBs (for Doria (Ed.), et al. Expires February 2, 2006 [Page 41] Internet-Draft ForCES August 2005 instance, in order to disable the LFB) must result in an error. Moreover, these LFBs must exist before the first ForCES message can be sent or received. All attributes in these LFBs must have pre- defined default values. Finally, these LFBs do not have input or output ports and do not integrate into the intra-FE LFB topology. 6.2.1. FE Protocol LFB The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The FE Protocol LFB Class ID is assigned the value 0x1. The FE Protocol LFB Instance ID is assigned the value 0x1. There MAY be one and only one instance of the FE Protocol LFB in an FE. The values of the attributes in the FE Protocol LFB have pre-defined default values that are specified here. Unless explicit changes are made to these values using Config messages from the CE, these default values MUST be used for the operation of the protocol. The formal definition of the FE Protocol LFB can be found in Appendix C The FE Protocol LFB consists of the following elements: o FE Protocol events that can be subscribed/unsubscribed: * FE heartbeat o FE Protocol capabilities (read-only): * Supported ForCES protocol version(s) by the FE * Supported ForCES FE model(s) by the FE * Some TML capability description(s) o FE Protocol attributes (can be read and set): * Current version of the ForCES protocol * Current version of the FE model * FE unicast ID * FE multicast ID(s) (list) * Association Expiry Timer. Defualt Value = 900 msec Doria (Ed.), et al. Expires February 2, 2006 [Page 42] Internet-Draft ForCES August 2005 * Heartbeat Interval. Defualt Value = 300 msec * Primary CE * FE restart policy - This specifies the behavior of the FE during a FE restart. The restart may be from a FE failure or other reasons that have made FE down and then need to restart. The values are defined as below: 0(default)- just restart the FE from scratch. In this case, the FE should start from pre-association phase definitely. 1 - restart the FE from an intermediate state. In this case, the FE itself decides from which state it restarts. For example, if the FE still keeps enough infomation of pre- association phase after some failure, it then has the right just to start from post-associatin phase with this policy case. Others - Reserved * CE failover policy - This specifies the behavior of the FE during a CE failure and restart time interval, or when the FE loses the CE association. A timeout parameter is associated with this attribute. (The default value for the timeout is set to 30 seconds). Values of this policy are defined as below: 0(default) - The FE should continue running and do what it can even without an associated CE. This basically makes the FE support CE Graceful restart. Note that if the CE still has not been restarted or hasn't been associated back to the FE, after a time interval specified by the timeout parameter, the FE will go down completely. 1 - FE should go down to stop functioning immediately. 2 - FE should go inactive to temporarily stop functioning. If the CE still has not been restarted after a time interval of specified by the timeout parameter, the FE will go down completely. Others - Reserved 6.2.2. FE Object LFB The FE Object LFB is a logical entity in each FE and contains attributes relative to the FE itself, and not to the operation of the ForCES protocol. The FE LFB Class ID is assigned the value 0x2. The Doria (Ed.), et al. Expires February 2, 2006 [Page 43] Internet-Draft ForCES August 2005 FE LFB Instance ID is assigned the value 0x1. There must always be one and only one instance of the FE Object LFB in an FE. The formal definition of the FE Object LFB can be found in [FE-MODEL] The FE Object LFB consists of the following elements: FE Events: * FEAllEvents: subscribing to this corresponds to subscribing to all events below * FEStatusChange: events that signal FE Status: + Up + Down + Active + Inactive + Failover * FE DoS alert * FE capability change FE attributes: * FEStatus: to set the FE mode as: + Active + Inactive + Shutdown * FELFBInstancelist * FENeighborList * MIID table: a list of virtual LFB Instance IDs that map to a list of Instance IDs of LFBs in that FE * FE Behavior Exp. Timer Doria (Ed.), et al. Expires February 2, 2006 [Page 44] Internet-Draft ForCES August 2005 * HA Mode * FE DoS protection policy * FEPrivateData: Proprietary info such as name, vendor, model. * Inter-FE topology Intra-FE topology --=-JCSh3hFah0fmtnZcjomE-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 22:55:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQFj1-00039A-TH for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 22:55:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12095 for ; Thu, 13 Oct 2005 22:55:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQFtb-0004K8-80 for forces-archive@IETF.ORG; Thu, 13 Oct 2005 23:06:15 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0110F21E@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 22:55:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87970415 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 22:55:09 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 22:55:09 -0400 Received: from [71.254.23.91] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12660991 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 20:54:36 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E07096175@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051013225410.0317e008@localhost> Date: Thu, 13 Oct 2005 22:55:03 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: updated text on HA section To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E07096175@orsmsx408> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 I think the main point we are making here is that while we are putting in hooks to support full redundancy, we are not claiming to have built all the pieces that are needed. We have not even built all the hooks probably. We need to be clear about that. Yours, Joel At 06:50 PM 10/13/2005, Khosravi, Hormuzd M wrote: >Good point Furquan. > >I am not sure we can solve this in an elegant way or any way without some >sort of CE-to-CE communication mechanism. >I'll send out the text with the addition of the CE Multicast ID case as >Jamal suggested, but that might not be directly applicable for this case. > >We can definitely mention this as an issue in the draft and propose some >solutions based on CE-to-CE mechanisms, which are not yet defined. > >Thanks for reviewing this! >Hormuzd > > >---------- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Furquan A. Ansari >Sent: Thursday, October 13, 2005 9:03 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] updated text on HA section > >Hello Hormuzd/all, > Haven't been closely following the discussion recently on the > mailing list since I was quite >busy with a few things. However, after quickly going through the HA >support section, I would be >hesitant to put this in the current draft. I feel that the HA situation is >more complicated than >spelled out here and in fact could/should come as a separate draft in its >own right. > >Here are a few things that complicate the situation: >1) In an NE with multiple CEs (Active and backups) and FEs, it is >mentioned that a communication >failure between a CE and an FE - due to either link reasons or CE failure >- it would trigger the FE to >switch over to the backup (using PL/TML) CE. This can lead to a "very bad >situation" in case of loss >of communication due to link failure. We do not want to be in a situation >where only "one" of the FEs is >now being managed/controlled by the backup CE while all other FEs are >being controlled by the active >CE (since the active CE is still functional and the loss of association >between the active CE and one of >the FEs in question occured either due to link failure or TML channel >failure etc.). This not only >destroys the notion of the having a single active CE within an NE (since >we now have the original active >CE still controlling the other FEs along with the backup CE now acting as >an active CE for "one" FE), but >making the whole collection of CE and FEs function together as a single NE >would be close to impossible, >since higher layer applications such as routing protocols etc. will now >have to be run from both the CEs. > >So, essentially, I would say that there are a few choices we have: >1) If one of the FEs is switching over to the backup CE, then all other >FEs will have to switch over the >backup CE as well > - Don't like this choice very much, because this would cause great > disruption at the network level since applications will have to be > restarted at the backup (e.g. routing protocols) >2) When a majority/all of the FEs are reporting loss of the connectivity >to the active CE (reported to the backup CE), only then should the backup >CE take over the functionality as the active CE. > - Better choice than before, but still not the best one - since what > happens to the FEs that are not >reachable by the active CE? How do we establish control over them since >the communication is lost? >Should the backup CE somehow help this FE in trying to establish the >connection/association back to the active CE? > >I can go on with many scenarios, but will stop here for now. > >Regards, > > >Khosravi, Hormuzd M wrote: >>The text is attached as per the protocol team discussions. >> >>regards >>Hormuzd >> >> >> >> >>8. High Availability Support >> >>The ForCES protocol provides mechanisms for CE redundancy and failover, >>in order to support High Availability as defined in [RFC3654]. FE >>redundancy >>and FE to FE interaction is currently out of scope of this draft. There >>can be multiple redundant CEs and FEs in a ForCES NE. However, at any >>time there can only be one Primary CE controlling the FEs and there can >>be multiple secondary CEs. The FE and the CE PL are aware of the primary >>and secondary CEs. This information (primary, secondary CEs) is configured >>in the FE, CE PLs during pre-association by FEM, CEM respectively. Only >>the primary CE sends Control messages to the FEs. >> >>There are 2 modes of HA defined in the ForCES protocol, Report Primary Mode >>and Report All Mode. The Report Primary Mode is the default mode of the >>protocol, >>in which the FEs only associate with one CE (primary) at a time. The >>Report All >>mode is for future study and not part of the current protocol version. In >>this mode, >>the FE would establish association with multiple CEs (primary & >>secondary) and >>report events, packets, Heart Beats to all the CEs. However, only the >>primary CE >>would configure/control the FE in this mode as well. This helps with >>keeping state >>between CEs synchronized, although it does not guarantee synchronization. >> >>The HA Modes are configured during Association setup phase, currently >>only Report >>Primary Mode is configured. A CE-to-CE synchronization protocol will be >>needed >>to support fast failover, however this will not be defined by the ForCES >>protocol. >> >>During a communication failure between the FE and CE (which is caused due >>to CE >>or link reasons, i.e. not FE related), the TML on the FE will trigger the >>FE PL >>regarding this failure. This can also be detected using the HB messages >>between >>FEs and CEs. The communication failure (detected via either of the two >>means >>described before) is considered as a loss of association between the CE and >>corresponding FE and the FE PL must establish association with the >>secondary CE at >>this point. During this phase, if the original primary CE comes alive >>and starts >>sending any commands to the FE, the FE should ignore those messages and >>send an >>Event to all CEs indicating its change in Primary CE. Thus the FE only >>has one >>primary CE at a time. >> >>An explicit message (Config message setting Primary CE attribute in >>ForCES Protocol >>object) from the primary CE, can also be used to change the Primary CE >>for an FE >>during normal protocol operation. >> > > >-- >Furquan Ansari >Bell Labs Research Ph : 732-949-5249 >Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 13 23:19:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQG6b-0002NE-Az for forces-archive@megatron.ietf.org; Thu, 13 Oct 2005 23:19:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13017 for ; Thu, 13 Oct 2005 23:19:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQGHE-0004pi-FX for forces-archive@IETF.ORG; Thu, 13 Oct 2005 23:30:37 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0110F3CE@cherry.ease.lsoft.com>; Thu, 13 Oct 2005 23:19:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87972890 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Oct 2005 23:19:34 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 13 Oct 2005 23:19:32 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Fri, 14 Oct 2005 11:59:43 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Fri, 14 Oct 2005 11:18:23 +0800 References: <1126115848.8422.47.camel@localhost.localdomain> <002401c5b53d$89ecd7c0$1152010a@Necom.hzic.edu.cn> <4325947C.501@zurich.ibm.com> <1126626769.6467.24.camel@localhost.localdomain> <43283519.1000905@zurich.ibm.com> <00b101c5b94a$2bce5c70$1f12fea9@wwm1> <1126717233.7551.25.camel@localhost.localdomain> <008801c5ba73$75f59000$1152010a@Necom.hzic.edu.cn> <1126885065.24495.32.camel@localhost.localdomain> <005701c5bd8d$5d301dc0$1f12fea9@wwm1> <1127233875.6535.67.camel@localhost.localdomain> <009801c5be5b$fba76480$1152010a@Necom.hzic.edu.cn> <1127298463.6447.39.camel@localhost.localdomain> <00a501c5bece$622046b0$1f12fea9@wwm1> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <016a01c5d06d$c80d3a90$1152010a@Necom.hzic.edu.cn> Date: Fri, 14 Oct 2005 11:17:07 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Jamal, When I check back the mail, I find the supposed changes on section 6.2.1 and even for 6.9 Heartbeat Message have already been proposed before, only the text seems was not included in the draft timely. I actually redid the HB message yesterday , for I also forgot I had already done this. Yours, Weiming ----- Original Message ----- From: "Weiming Wang" > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > > Send me the text privately when ready and i will release it to the list. > > Jamal, I think it may be better for you to keep consistency with your XML file > version maintainence by my sending you only the text instead of the XML. The > text regarding the Heartbeat attributes in FEPO is just as below: > > Remove the following text in Section 6.2.1 on the FE Protocol Attributes > paragraph: > > --- > * Association Expiry Timer. Defualt Value = 900 msec > > * Heartbeat Interval. Defualt Value = 300 msec > --- > The reason to remove the Association Expiry Timer is, it can simply be replaced > by the 'CE heartbeat dead interval', I think. Any comments ? > > Substitute it with the following text: > > --- > * Heartbeat policy and parameters, which includes fields as: > > . CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat > Dead Interval (CE HDI)' as described below, actually tells the FE how to check > the CE liveness. The policy values with its meanings are listed as below: > > 0(default) - This policy specifies that CE will send a Heartbeat > Message to FE whenever CE reaches a time interval within which no any other > messages were sent from CE to FE (Heartbeat generated in this way is sometimes > called Piggybacking-Heartbeat). A CE HDI parameter as described below is > associated with this policy. FE checks the CE being alive or dead just by > checking if it has or has not received any message (including Heartbeat Message > itself) for the CE HDI period. Note that CE can freely choose the time interval > to send Heartbeat messages and don't have to let FE know the interval, but > definitely, the time interval choosen must be smaller than the CE HDI assigned. > > 1 - This policy specifies that CE will not send any Heartbeat Message > to FE in any case. This actually means CE does not want to ask FE to check the > CE liveness. > > Others - reserved. > > . FE heartbeat policy - This policy, along with the parameter 'FE Heartbeat > Interval (FE HI)', tells FE how it should act so that the CE it has associated > with can check the liveness of the FE based on the actions. The policy values > and the meanings are: > > 0(default) - This policy actually specifies no extra action for FE on > its heartbeat generation. As a result, to let CE check its liveness, the FE may > only just act by responding to CE whenever CE sends Heartbeat Request Message > (also a normal HB message, only with whose ACK flag is set to AlwaysACK, see > Section 6.9) with a Heartbeat Response Message (also a normal HB message, only > with whose ACK flag is set to NoACK, see Section 6.9). > > 1 - This policy specifies that FE must actively send a Heartbeat > Message if it reaches the time interval assigned by the FE HI followed, within > which no any other messages were sent from FE to CE. > > Others - Reserved. > > . CE Heartbeat Dead Interval (CE HDI) - to tell FE the time interval the FE > uses to check the CE liveness. If FE has not received any messages from CE for > this time interval, FE may make a conclusion that the CE is dead or the > association to the CE is lost. > > . FE Heartbeat Interval (FE HI) - to command FE to use the interval for the > FE Heartbeat Message generation. If set to 0, it means FE must choose a default > value. (Comments: Note that CE does not need to set heartbeat dead interval for > FE.) > > --- > > Because of the change with the ACK flag usage in Heartbeat Message, Section 6.9 > Heartbeat Message should also be changed. I propose the text as below: > > --- > 6.9 Heartbeat Message > > The Heartbeat (HB) Message is used for one ForCES element (FE or CE) > to asynchronously notify one or more other ForCES elements in the > same ForCES NE on its liveness. > > A Heartbeat Message may be sent by CE or FE. The policies and the related > parameters for CE or FE to generate and send Heartbeat Messages are defined as > an attribute of FE protocol LFB, as described in Section 6.2.1 and also formally > defined in Appendix C. > A Heartbeat Message is, in its PDU, only composed of a common header, with > the message body left empty. Detailed description of the message is as below. > > Message Transfer Direction: > FE to CE, or CE to FE > > Message Header: > The Message Type in the message header is set to MessageType = > 'Heartbeat'. The ACK flag in the header can be set to the value of 'NoACK' or > 'AlwaysACK' as defined in Section 5.1. The default behavior for the ACK flag > that is set to any other value is defined just as the behavior of 'NoACK'. When > set to 'NoACK', the message will not expect any response from the receiver. When > set to 'AlwaysACK', the Heartbeat Message is then called a Heartbeat Request > Message, and will then expect a response from its receiver. There is no a > specific Heartbeat Response Message defined. A normal Heartbeat Message will act > as a response to a Heartbeat Request Message by its correlator set to that of > the responding Heartbeat Request Message and by its ACK flag always set to > 'NoACK'. Current heartbeat policies as defined in Section 6.2.1 only allow a > Heartbeat Request Message being sent from CE to FE rather than contrary. > > Message Body: > The message body is empty for the Heartbeat Message. > > --- > > Thanks, > Weiming From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 01:30:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQI8w-0002zy-Li for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 01:30:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18563 for ; Fri, 14 Oct 2005 01:30:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQIJb-0007wl-Ak for forces-archive@IETF.ORG; Fri, 14 Oct 2005 01:41:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0110F740@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 1:30:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87982298 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 01:30:06 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 01:30:06 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9E5U6Td023568; Fri, 14 Oct 2005 05:30:06 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9E5Txkb024151; Fri, 14 Oct 2005 05:30:06 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101322300509542 ; Thu, 13 Oct 2005 22:30:05 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Oct 2005 22:30:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] updated text on HA section Thread-Index: AcXQarWuJEVOUrx1RZeJbkK7TA/F5QAFZKjg X-OriginalArrivalTime: 14 Oct 2005 05:30:05.0824 (UTC) FILETIME=[5577E800:01C5D080] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E07096531@orsmsx408> Date: Thu, 13 Oct 2005 22:30:02 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: updated text on HA section Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: quoted-printable Fair enough, I'll add that note. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, October 13, 2005 7:55 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] updated text on HA section I think the main point we are making here is that while we are putting in=20 hooks to support full redundancy, we are not claiming to have built all the=20 pieces that are needed. We have not even built all the hooks probably. We need to be clear about that. Yours, Joel At 06:50 PM 10/13/2005, Khosravi, Hormuzd M wrote: >Good point Furquan. > >I am not sure we can solve this in an elegant way or any way without some=20 >sort of CE-to-CE communication mechanism. >I'll send out the text with the addition of the CE Multicast ID case as >Jamal suggested, but that might not be directly applicable for this case. > >We can definitely mention this as an issue in the draft and propose some=20 >solutions based on CE-to-CE mechanisms, which are not yet defined. > >Thanks for reviewing this! >Hormuzd > > >---------- >From: Forwarding and Control Element Separation=20 >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Furquan A. Ansari >Sent: Thursday, October 13, 2005 9:03 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] updated text on HA section > >Hello Hormuzd/all, > Haven't been closely following the discussion recently on the=20 > mailing list since I was quite >busy with a few things. However, after quickly going through the HA=20 >support section, I would be >hesitant to put this in the current draft. I feel that the HA situation is=20 >more complicated than >spelled out here and in fact could/should come as a separate draft in its=20 >own right. > >Here are a few things that complicate the situation: >1) In an NE with multiple CEs (Active and backups) and FEs, it is=20 >mentioned that a communication >failure between a CE and an FE - due to either link reasons or CE failure=20 >- it would trigger the FE to >switch over to the backup (using PL/TML) CE. This can lead to a "very bad=20 >situation" in case of loss >of communication due to link failure. We do not want to be in a situation=20 >where only "one" of the FEs is >now being managed/controlled by the backup CE while all other FEs are=20 >being controlled by the active >CE (since the active CE is still functional and the loss of association >between the active CE and one of >the FEs in question occured either due to link failure or TML channel=20 >failure etc.). This not only >destroys the notion of the having a single active CE within an NE (since=20 >we now have the original active >CE still controlling the other FEs along with the backup CE now acting as=20 >an active CE for "one" FE), but >making the whole collection of CE and FEs function together as a single NE=20 >would be close to impossible, >since higher layer applications such as routing protocols etc. will now >have to be run from both the CEs. > >So, essentially, I would say that there are a few choices we have: >1) If one of the FEs is switching over to the backup CE, then all other >FEs will have to switch over the >backup CE as well > - Don't like this choice very much, because this would cause great > disruption at the network level since applications will have to be=20 > restarted at the backup (e.g. routing protocols) >2) When a majority/all of the FEs are reporting loss of the connectivity=20 >to the active CE (reported to the backup CE), only then should the backup=20 >CE take over the functionality as the active CE. > - Better choice than before, but still not the best one - since what=20 > happens to the FEs that are not >reachable by the active CE? How do we establish control over them since >the communication is lost? >Should the backup CE somehow help this FE in trying to establish the=20 >connection/association back to the active CE? > >I can go on with many scenarios, but will stop here for now. > >Regards, > > >Khosravi, Hormuzd M wrote: >>The text is attached as per the protocol team discussions. >> >>regards >>Hormuzd >> >> >> >> >>8. High Availability Support >> >>The ForCES protocol provides mechanisms for CE redundancy and failover, >>in order to support High Availability as defined in [RFC3654]. FE=20 >>redundancy >>and FE to FE interaction is currently out of scope of this draft. There >>can be multiple redundant CEs and FEs in a ForCES NE. However, at any >>time there can only be one Primary CE controlling the FEs and there can >>be multiple secondary CEs. The FE and the CE PL are aware of the primary >>and secondary CEs. This information (primary, secondary CEs) is configured >>in the FE, CE PLs during pre-association by FEM, CEM respectively. Only >>the primary CE sends Control messages to the FEs. >> >>There are 2 modes of HA defined in the ForCES protocol, Report Primary Mode >>and Report All Mode. The Report Primary Mode is the default mode of the=20 >>protocol, >>in which the FEs only associate with one CE (primary) at a time. The=20 >>Report All >>mode is for future study and not part of the current protocol version. In=20 >>this mode, >>the FE would establish association with multiple CEs (primary &=20 >>secondary) and >>report events, packets, Heart Beats to all the CEs. However, only the=20 >>primary CE >>would configure/control the FE in this mode as well. This helps with=20 >>keeping state >>between CEs synchronized, although it does not guarantee synchronization. >> >>The HA Modes are configured during Association setup phase, currently=20 >>only Report >>Primary Mode is configured. A CE-to-CE synchronization protocol will be=20 >>needed >>to support fast failover, however this will not be defined by the ForCES=20 >>protocol. >> >>During a communication failure between the FE and CE (which is caused due=20 >>to CE >>or link reasons, i.e. not FE related), the TML on the FE will trigger the=20 >>FE PL >>regarding this failure. This can also be detected using the HB messages=20 >>between >>FEs and CEs. The communication failure (detected via either of the two=20 >>means >>described before) is considered as a loss of association between the CE and >>corresponding FE and the FE PL must establish association with the=20 >>secondary CE at >>this point. During this phase, if the original primary CE comes alive >>and starts >>sending any commands to the FE, the FE should ignore those messages and=20 >>send an >>Event to all CEs indicating its change in Primary CE. Thus the FE only=20 >>has one >>primary CE at a time. >> >>An explicit message (Config message setting Primary CE attribute in=20 >>ForCES Protocol >>object) from the primary CE, can also be used to change the Primary CE >>for an FE >>during normal protocol operation. >> > > >-- >Furquan Ansari >Bell Labs Research Ph : 732-949-5249 >Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 03:10:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJi5-0007eg-Tg for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 03:10:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22078 for ; Fri, 14 Oct 2005 03:10:28 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQJsk-0001vF-Ox for forces-archive@IETF.ORG; Fri, 14 Oct 2005 03:21:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0110F9A3@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 3:10:31 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87986310 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 03:10:25 -0400 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 03:10:21 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOC00D2C9NML7@szxga02-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 15:18:59 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOC00HQU9NMBS@szxga02-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 15:18:58 +0800 (CST) Received: from lenovo111 ([10.110.100.34]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOC008819SP4E@szxml01-in.huawei.com>; Fri, 14 Oct 2005 15:22:01 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <044f01c5cfdc$ab642930$22646e0a@china.huawei.com> <6.2.1.2.0.20051013085739.02f92610@localhost> Approved-By: Xiaoyi Guo Message-ID: <00ae01c5d08e$752b42b0$22646e0a@china.huawei.com> Date: Fri, 14 Oct 2005 15:11:11 +0800 Reply-To: Xiaoyi Guo Sender: Forwarding and Control Element Separation From: Xiaoyi Guo Organization: Huawei Tech. Subject: Re: ForCES Intra-NE routing mechanism Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7BIT hi, Joel. Best Regards! Xiaoyi . ----- Original Message ----- From: "Joel M. Halpern" >I am not sure I follow this discussion. > 1) The CE can use any algorithm it likes to calculate paths. (That applies > both to intra-NE paths and to normal routing. ForCES does not care what > path computation algorithm is used by the CE.) > Yes, you are right. ForCES does not care the algorithm , but i think we can find a better algorithm for Intra-NE. So I prefer a implement for it. > 2) I don't see the value in creating a new kind of forwarding table. For > each FE, the forwarding table it is given ought to translate an IP prefix > into a next hop, and the next hop into an egress port. You seem to be > trying to add a third layer of mapping. The benefit I can see for such a > thing might be that it could reduce slightly the differences in the tables > across the FEs. However, I would be really unhappy at mandating such an > architecture. > I think i can understand your comments and your thoughts. So i will give more information about this mechanism. if one NE include many FEs , there exist many paths cross the Intra-NE. Let's suppose one of the paths cross many FEs such as 10 FEs, but only the two edge FEs have the connection to other routers, the other 8 FEs are intra-FEs. I think they don't need the information of outside routers , even they can be configured with private ip addr. So these 8 FE just have the intra- fowarding table as i metioned . That the reason why i suggest this multi-hop forwarding mechanism. From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 03:11:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJiX-0007iC-HA for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 03:11:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22090 for ; Fri, 14 Oct 2005 03:10:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQJtD-0001vg-6H for forces-archive@IETF.ORG; Fri, 14 Oct 2005 03:22:03 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0110F957@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 3:11:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87986323 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 03:10:58 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 03:10:58 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9E7Awm0024202 for ; Fri, 14 Oct 2005 07:10:58 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9E7Ahkx005065 for ; Fri, 14 Oct 2005 07:10:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101400105722697 for ; Fri, 14 Oct 2005 00:10:57 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 00:10:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5D08E.6C6E1606" X-MS-Has-Attach: yes Thread-Topic: updated text on HA section Thread-Index: AcXPdUt6WLMCFpNyRU6ADvYKl0rbbABFOiUA X-OriginalArrivalTime: 14 Oct 2005 07:10:57.0781 (UTC) FILETIME=[6CB74250:01C5D08E] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0709657B@orsmsx408> Date: Fri, 14 Oct 2005 00:10:56 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: updated text on HA section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.2 (+) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D08E.6C6E1606 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5D08E.6C6E1606" ------_=_NextPart_002_01C5D08E.6C6E1606 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HA section text attached. Incorporated latest feedback.=20 Jamal, pls feel free to make any more changes if need be, =20 Thanks Hormuzd=20 =20 ________________________________ From: Khosravi, Hormuzd M=20 Sent: Wednesday, October 12, 2005 2:39 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: updated text on HA section =20 The text is attached as per the protocol team discussions. =20 regards Hormuzd =20 ------_=_NextPart_002_01C5D08E.6C6E1606 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HA section text attached. = Incorporated latest feedback.

Jamal, pls feel free to make any = more changes if need be,

 

Thanks

Hormuzd

 

From: = Khosravi, Hormuzd M
Sent: Wednesday, October = 12, 2005 2:39 PM
To: = FORCES@PEACH.EASE.LSOFT.COM
Subject: updated text on = HA section

 

The text is attached as per the protocol team discussions.

 

regards

Hormuzd

 

------_=_NextPart_002_01C5D08E.6C6E1606-- ------_=_NextPart_001_01C5D08E.6C6E1606 Content-Type: text/plain; name="ha-section.txt" Content-Transfer-Encoding: base64 Content-Description: ha-section.txt Content-Disposition: attachment; filename="ha-section.txt" Content-Transfer-Encoding: base64 OC4gSGlnaCBBdmFpbGFiaWxpdHkgU3VwcG9ydA0KDQpUaGUgRm9yQ0VTIHByb3RvY29sIHByb3Zp ZGVzIG1lY2hhbmlzbXMgZm9yIENFIHJlZHVuZGFuY3kgYW5kIGZhaWxvdmVyLCANCmluIG9yZGVy IHRvIHN1cHBvcnQgSGlnaCBBdmFpbGFiaWxpdHkgYXMgZGVmaW5lZCBpbiBbUkZDMzY1NF0uICBG RSByZWR1bmRhbmN5IA0KYW5kIEZFIHRvIEZFIGludGVyYWN0aW9uIGlzIGN1cnJlbnRseSBvdXQg b2Ygc2NvcGUgb2YgdGhpcyBkcmFmdC4gIFRoZXJlIA0KY2FuIGJlIG11bHRpcGxlIHJlZHVuZGFu dCBDRXMgYW5kIEZFcyBpbiBhIEZvckNFUyBORS4gIEhvd2V2ZXIsIGF0IGFueSANCnRpbWUgdGhl cmUgY2FuIG9ubHkgYmUgb25lIFByaW1hcnkgQ0UgY29udHJvbGxpbmcgdGhlIEZFcyBhbmQgdGhl cmUgY2FuIA0KYmUgbXVsdGlwbGUgc2Vjb25kYXJ5IENFcy4gIFRoZSBGRSBhbmQgdGhlIENFIFBM IGFyZSBhd2FyZSBvZiB0aGUgcHJpbWFyeSANCmFuZCBzZWNvbmRhcnkgQ0VzLiAgVGhpcyBpbmZv cm1hdGlvbiAocHJpbWFyeSwgc2Vjb25kYXJ5IENFcykgaXMgY29uZmlndXJlZCANCmluIHRoZSBG RSwgQ0UgUExzIGR1cmluZyBwcmUtYXNzb2NpYXRpb24gYnkgRkVNLCBDRU0gcmVzcGVjdGl2ZWx5 LiAgT25seSANCnRoZSBwcmltYXJ5IENFIHNlbmRzIENvbnRyb2wgbWVzc2FnZXMgdG8gdGhlIEZF cy4gDQoNClRoZXJlIGFyZSAyIG1vZGVzIG9mIEhBIGRlZmluZWQgaW4gdGhlIEZvckNFUyBwcm90 b2NvbCwgUmVwb3J0IFByaW1hcnkgTW9kZSANCmFuZCBSZXBvcnQgQWxsIE1vZGUuIFRoZSBSZXBv cnQgUHJpbWFyeSBNb2RlIGlzIHRoZSBkZWZhdWx0IG1vZGUgb2YgdGhlIHByb3RvY29sLCANCmlu IHdoaWNoIHRoZSBGRXMgb25seSBhc3NvY2lhdGUgd2l0aCBvbmUgQ0UgKHByaW1hcnkpIGF0IGEg dGltZS4gVGhlIFJlcG9ydCBBbGwgDQptb2RlIGlzIGZvciBmdXR1cmUgc3R1ZHkgYW5kIG5vdCBw YXJ0IG9mIHRoZSBjdXJyZW50IHByb3RvY29sIHZlcnNpb24uIEluIHRoaXMgbW9kZSwgDQp0aGUg RkUgd291bGQgZXN0YWJsaXNoIGFzc29jaWF0aW9uIHdpdGggbXVsdGlwbGUgQ0VzIChwcmltYXJ5 ICYgc2Vjb25kYXJ5KSBhbmQgDQpyZXBvcnQgZXZlbnRzLCBwYWNrZXRzLCBIZWFydCBCZWF0cyB0 byBhbGwgdGhlIENFcy4gSG93ZXZlciwgb25seSB0aGUgcHJpbWFyeSBDRSANCndvdWxkIGNvbmZp Z3VyZS9jb250cm9sIHRoZSBGRSBpbiB0aGlzIG1vZGUgYXMgd2VsbC4gVGhpcyBoZWxwcyB3aXRo IGtlZXBpbmcgc3RhdGUgDQpiZXR3ZWVuIENFcyBzeW5jaHJvbml6ZWQsIGFsdGhvdWdoIGl0IGRv ZXMgbm90IGd1YXJhbnRlZSBzeW5jaHJvbml6YXRpb24uIA0KDQpUaGUgSEEgTW9kZXMgYXJlIGNv bmZpZ3VyZWQgZHVyaW5nIEFzc29jaWF0aW9uIHNldHVwIHBoYXNlLCBjdXJyZW50bHkgb25seSBS ZXBvcnQgDQpQcmltYXJ5IE1vZGUgaXMgY29uZmlndXJlZC4gIEEgQ0UtdG8tQ0Ugc3luY2hyb25p emF0aW9uIHByb3RvY29sIHdpbGwgYmUgbmVlZGVkIA0KdG8gc3VwcG9ydCBmYXN0IGZhaWxvdmVy IGFzIHdlbGwgYXMgYWRkcmVzcyBzb21lIG9mIHRoZSBjb3JuZXIgY2FzZXMsIGhvd2V2ZXIgdGhp cyANCndpbGwgbm90IGJlIGRlZmluZWQgYnkgdGhlIEZvckNFUyBwcm90b2NvbCAoc2luY2UgaXQg aXMgb3V0IG9mIHNjb3BlKS4NCg0KRHVyaW5nIGEgY29tbXVuaWNhdGlvbiBmYWlsdXJlIGJldHdl ZW4gdGhlIEZFIGFuZCBDRSAod2hpY2ggaXMgY2F1c2VkIGR1ZSB0byBDRSANCm9yIGxpbmsgcmVh c29ucywgaS5lLiBub3QgRkUgcmVsYXRlZCksIHRoZSBUTUwgb24gdGhlIEZFIHdpbGwgdHJpZ2dl ciB0aGUgRkUgUEwgDQpyZWdhcmRpbmcgdGhpcyBmYWlsdXJlLiAgVGhpcyBjYW4gYWxzbyBiZSBk ZXRlY3RlZCB1c2luZyB0aGUgSEIgbWVzc2FnZXMgYmV0d2VlbiANCkZFcyBhbmQgQ0VzLiAgVGhl IGNvbW11bmljYXRpb24gZmFpbHVyZSAoZGV0ZWN0ZWQgdmlhIGVpdGhlciBvZiB0aGUgdHdvIG1l YW5zIA0KZGVzY3JpYmVkIGJlZm9yZSkgaXMgY29uc2lkZXJlZCBhcyBhIGxvc3Mgb2YgYXNzb2Np YXRpb24gYmV0d2VlbiB0aGUgQ0UgYW5kIA0KY29ycmVzcG9uZGluZyBGRSBhbmQgdGhlIEZFIFBM IG11c3QgZXN0YWJsaXNoIGFzc29jaWF0aW9uIHdpdGggdGhlIHNlY29uZGFyeSBDRSBhdCANCnRo aXMgcG9pbnQuICBEdXJpbmcgdGhpcyBwaGFzZSwgaWYgdGhlIG9yaWdpbmFsIHByaW1hcnkgQ0Ug Y29tZXMgYWxpdmUgYW5kIHN0YXJ0cyANCnNlbmRpbmcgYW55IGNvbW1hbmRzIHRvIHRoZSBGRSwg dGhlIEZFIHNob3VsZCBpZ25vcmUgdGhvc2UgbWVzc2FnZXMgYW5kIHNlbmQgYW4gDQpFdmVudCB0 byBhbGwgQ0VzIGluZGljYXRpbmcgaXRzIGNoYW5nZSBpbiBQcmltYXJ5IENFLiAgVGh1cyB0aGUg RkUgb25seSBoYXMgb25lIA0KcHJpbWFyeSBDRSBhdCBhIHRpbWUuDQoNCkFuIGV4cGxpY2l0IG1l c3NhZ2UgKENvbmZpZyBtZXNzYWdlIHNldHRpbmcgUHJpbWFyeSBDRSBhdHRyaWJ1dGUgaW4gRm9y Q0VTIFByb3RvY29sIA0Kb2JqZWN0KSBmcm9tIHRoZSBwcmltYXJ5IENFLCBjYW4gYWxzbyBiZSB1 c2VkIHRvIGNoYW5nZSB0aGUgUHJpbWFyeSBDRSBmb3IgYW4gRkUgDQpkdXJpbmcgbm9ybWFsIHBy b3RvY29sIG9wZXJhdGlvbi4NCg0KQWxzbyBub3RlIHRoYXQgdGhlIEZFcyBpbiBhIEZvckNFUyBO RSBjb3VsZCBhbHNvIHVzZSBhIG11bHRpY2FzdCBDRUlELCBpLmUuIHRoZXkgYXJlDQphc3NvY2lh dGVkIHdpdGggYSBncm91cCBvZiBDRXMgKGFzc3VtZXMgc29tZSBmb3JtIG9mIENFLUNFIHN5bmNo cm9uaXphdGlvbiBwcm90b2NvbCkuDQpJbiB0aGlzIGNhc2UgdGhlIGxvc3Mgb2YgYXNzb2NpYXRp b24gd291bGQgbWVhbiB0aGF0IGNvbW11bmljYXRpb24gd2l0aCB0aGUgZW50aXJlDQptdWx0aWNh c3QgZ3JvdXAgb2YgQ0VzIGhhcyBiZWVuIGxvc3QuIFRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBh Ym92ZSB3aWxsIGFwcGx5DQpmb3IgdGhpcyBjYXNlIGFzIHdlbGwgZHVyaW5nIHRoZSBsb3NzIG9m IGFzc29jaWF0aW9uLg0K ------_=_NextPart_001_01C5D08E.6C6E1606-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 05:38:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQM1c-0003am-TD for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 05:38:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28362 for ; Fri, 14 Oct 2005 05:38:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQMCJ-0005qc-Si for forces-archive@IETF.ORG; Fri, 14 Oct 2005 05:49:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0110F934@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 5:38:51 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87995410 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 05:38:40 -0400 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 05:38:39 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOC005GQGI1WJ@szxga02-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 17:46:49 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOC00F62GHYNY@szxga02-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 17:46:49 +0800 (CST) Received: from lenovo111 ([10.110.100.34]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOC00E6CGN86Z@szxml01-in.huawei.com>; Fri, 14 Oct 2005 17:49:56 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <468F3FDA28AA87429AD807992E22D07E0705D5CA@orsmsx408> Approved-By: Xiaoyi Guo Message-ID: <011801c5d0a3$1f2a9c20$22646e0a@china.huawei.com> Date: Fri, 14 Oct 2005 17:39:06 +0800 Reply-To: Xiaoyi Guo Sender: Forwarding and Control Element Separation From: Xiaoyi Guo Organization: Huawei Tech. Subject: Re: ForCES Intra-NE routing mechanism Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7BIT hi, Hormuzd, Yes , this is what i think in mind. I already take a look at the Topology draft several times. And when i write this draft , i think i should add this section here for clarity . If others also take this point as you , i will delete these contents from my draft later. Best Reards, Xiaoyi. ----- Original Message ----- From: "Khosravi, Hormuzd M" To: Sent: Friday, October 14, 2005 3:07 AM Subject: Re: ForCES Intra-NE routing mechanism I think this could be a good Informational RFC at the least. I am not sure if this is what Xiaoyi Guo has in mind, but I wouldn't have any objection to having an informational rfc on this. Xiaoyi Guo, you should look at the Topology draft as well, there is some overlap here. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern 2) I don't see the value in creating a new kind of forwarding table. For each FE, the forwarding table it is given ought to translate an IP prefix into a next hop, and the next hop into an egress port. You seem to be trying to add a third layer of mapping. The benefit I can see for such a thing might be that it could reduce slightly the differences in the tables across the FEs. However, I would be really unhappy at mandating such an architecture. Yours, Joel At 05:58 AM 10/13/2005, Xiaoyi Guo wrote: >All, > >I'm currently putting a draft of the ForCES Intra-NE routing mechaniam, >and will submit it by Thusday.Below are the major points, please comment. > >About ForCES Intra-NE routing mechanism > ----------------- > | CE | > ----------------- > A ^ B ^ C ^ > / | \ > / A v \ > / ------- B \ > / +->| FE3 |<-+ \ > / |C | | | \ > A v | ------- | v A > -------B | |E ------- > | FE1 |<-+ +->| FE2 | > | |<--------------->| | > ------- C D ------- > E ^ D| C ^ | B > | | | | > | v | v > >When a packet comes in FE1 port E and it want to forwaring to FE2 port B, >it must across the Intra-NE FEs. > >There has two ways to generate the routing paths : >1, static configuration from FEM / CEM , >2, dynamic generated by system . > >Obviously the first method is not a good choice , so we focus on the >latter one. >We aleardy know the full topology from the CE topology table , this is >designed and generated by >Intra-NE topology discovery mechanism. > >But this topology table need to caculate and generate to the CE's >Intra-routing table. >For example , in this Figure , there exist two path from FE1 to FE2, so we >must use some policy >to select a better one which the cost is smaller. The method maybe like >the OSPF SPF tree algorithm >or other similar algorithm. > >See the CE topology table >---------------------------------------------- > > FE1 B FE2 D > FE2 E FE3 D > FE1 B FE2 C > >We will add a Intra-FIB in each FE , this table is distributed by master CE: >i will add some structure such as nexthop(port) , nextNode(FE), so it >looks like a table as below > >FE1 IFIB (part) >----------------------------------------------------------------------- ------------------------- > > FE1 B FE3 D FE2 > D > > FE2 IFIB (part) >----------------------------------------------------------------------- ------------------------ > > FE2 E FE3 D FE3 > D > >When the packet arrived at FE1 , Then FE1 find the Nexthop by searching >FIB , >and then searching IFIB , FE1 will know the routing path is from FE1 to >FE3 then to FE2. In FE3 , >only search the IFIB, the packet forward to FE2 with the correct path , >then FE2 will forward it out the NE . > >This two table searching mechanism is a bit similar to such as MPLS or >other VPN label pursh/pop action. > >The advantages as below : >1, The Intra-NE full topylogy need not known by each FE. >2, Intra-FE do not need the outer routing information. > > >Best Regards > >Xiaoyi Guo >------------------------------------------------ >Huawei Technologies. >No. 3 Xinxi Rd., Shang-Di Information Industry Base, >Hai-Dian District Beijing, P.R. China 100085 >Tel: +86-10-8288-2290 >Fax: +86-10-8288-2770 ><mailto:xiaotian@huawei.com> > >------------------------------------------ From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 06:16:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMcP-0006cx-3l for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 06:16:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29956 for ; Fri, 14 Oct 2005 06:16:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQMn6-0006my-F5 for forces-archive@IETF.ORG; Fri, 14 Oct 2005 06:27:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0110F9CD@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 6:16:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88000160 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 06:16:46 -0400 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 06:16:42 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOC005BRI4TWJ@szxga02-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 18:22:06 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOC00L1BI4TBS@szxga02-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 18:22:05 +0800 (CST) Received: from lenovo111 ([10.110.100.34]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOC00FLKIA45B@szxml01-in.huawei.com>; Fri, 14 Oct 2005 18:25:17 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <434BB83B.5050100@zurich.ibm.com> <434E7051.4080500@zurich.ibm.com> Approved-By: Xiaoyi Guo Message-ID: <012101c5d0a8$0ef5cc80$22646e0a@china.huawei.com> Date: Fri, 14 Oct 2005 18:14:27 +0800 Reply-To: Xiaoyi Guo Sender: Forwarding and Control Element Separation From: Xiaoyi Guo Organization: Huawei Tech. Subject: Re: ForCES MIB: 1st draft Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7BIT hi, Robert , I read this draft again , and i think that the single NE MIB is a better choice. For in a multi-vendor environment , i prefer a standard protocol to support it. And i wouldn't have other suggestion on this. Regards, Xiaoyi ----- Original Message ----- From: "Robert Haas" To: Sent: Thursday, October 13, 2005 10:33 PM Subject: Re: ForCES MIB: 1st draft > All, > > Below is the 1st draft, which raises a few issues. > > Regards, > -Robert > > > > ForCES MIB > > (draft version 00-a) > > 0. Abstract > > This document specifies the ForCES MIB. > > > 1. Introduction > > The ForCES MIB is a read-only MIB that captures information related to > the ForCES protocol. This includes state information about the > associations between CE(s) and FE(s) in the NE. > [Note: anything else besides associations that the MIB should include?] > > The ForCES MIB does not include information that is specified in other > MIBs, such as packet counters for interfaces, etc. > > The information in the ForCES MIB relative to associations includes more > specifically: > > - identifiers of the elements in the association > - state of the association > - configuration parameters of the association > - statistics of the association > > The relevant references from the ForCES requirements and architecture > documents are repeated below: > > Requirements RFC 3654 http://www.ietf.org/rfc/rfc3654.txt > Section 4, point 4: > 4) A NE MUST support the appearance of a single functional device. > For example, in a router, the TTL of the packet should be decremented > only once as it traverses the NE regardless of how many FEs through > which it passes. However, external entities (e.g., FE managers and > CE managers) MAY have direct access to individual ForCES protocol > elements for providing information to transition them from the pre- > association to post-association phase. > > Section 4, point 14: > 1. The ability for a management tool (e.g., SNMP) to be used to read > (but not change) the state of FE SHOULD NOT be precluded. > 2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to > change the state of a FE in a manner that affects overall NE > behavior without the CE being notified. > > Architecture RFC 3746 http://www.ietf.org/rfc/rfc3746.txt > Section 3.3: > CE managers may be physically and logically separate > entities that configure the CE with FE information via such > mechanisms as COPS-PR [7] or SNMP [5]. > > Section 5.7: > 5.7. Application Layer -- Network Management Protocol > > RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP". > In general, for the post-association phase, most external management > tasks (including SNMP) should be done through interaction with the CE > in order to support the appearance of a single functional device. > Therefore, it is recommended that an SNMP agent be implemented by CEs > and that the SNMP messages received by FEs be redirected to their > CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here > such that CEs act in the role of master agent to process SNMP > protocol messages while FEs act in the role of subagent to provide > access to the MIB objects residing on FEs. AgentX protocol messages > between the master agent (CE) and the subagent (FE) are encapsulated > and transported via ForCES, just like data packets from any other > application layer protocols. > > > > 2. Design of ForCES MIB > > As state information is distributed across FEs and CEs, the following > alternatives may be considered: > > 1) CE MIBs > Each CE in the NE implements a CE MIB. The external SNMP-based > management tool must therefore be aware of each CE in order to obtain a > complete view of the NE by collecting state information obtained from > each CE MIB. > [Note: this may or may not comply with requirement #4 ("A NE MUST > support the appearance of a single functional device")] > > 2) single NE MIB > An entity in the NE implements an NE MIB that aggregates state > information collected from each CE (CEs are possibly from various > vendors). This requires a standard protocol in order to support > multi-vendor environment. AgentX with the NE as the master and the CE(s) > as the agent(s) may be considered here. > [Note: comments on the suitability of AgentX ?] > > [Note: none of the two alternatives are ideal ...] > > 3. Capturing State Before Association Establishment > > The ForCES protocol may be used by the CE to query the FE Protocol LFB > about some of the configuration parameters. But such queries may > obviously be issued only once the association is established. > > In the ForCES protocol, the FE first issues an Association Setup Request > message to the CE which in turns responds with an Association Setup > Response message. It may be useful to capture in the MIB in which state > the association is seen from each of the FE and the CE sides, as a means > to detect PL-level communication anomalies. For instance, from the FE > side, the association is in the ATTEMPT state as long as no response to > the Association Setup message has been received from the CE. Similarly, > the association is in the ESTABLISHING state as long as no message has > been received from the FE after the CE has issued a positive Association > Setup Response message (this is because configuration mistakes in the FE > may cause messages from the CE to be ignored, and the MIB could help in > tracing such errors). > > The transient state in the FE until the association is established > cannot be queried using ForCES. > [Note: If such information is critical, then an FE MIB has to be > provided that can be queried separately] > > > 4. MIB Definition(s) > > For each association identified by the pair CE ID and FE ID, the > following information is included in the MIB: > > [Note: the MIB includes all associations for the particular CE in the > case of a CE MIB, same for FE MIBs (if any), or all associations in the > NE in the case of a NE MIB] > > - Current state of the association: > > UP: the CE(s) indicated by the CE ID and FE(s) indicated by > the FE ID are associated. > ESTABLISHING/ATTEMPT: transient state unitl the association is > established. See section 3 above for details. > > Note that associations that are not UP and for which no association > setup is in progress are NOT listed in the MIB. > [Note: otherwise how do we decide which old associations to remove from > the MIB ?] > > - Hearbeat timers values of the FE and CE for this association. > > - Heartbeat timer settings of the FE and CE for this association: > > ENABLED: hearbeats are transmitted (by default virtual piggybacking > is used) > DISABLED: heartbeats are not transmitted > > - Backup information: the FE(s)/CE(s) that are configured to work as > backups for this association. > [Note: is this necessary, useful ?] > > - Association statistics: > Date/time when the association came to the UP state. > [Note: what about the Number of commands executed or some indications of > the ForCES control traffic ?] > > > TBD: actual MIB specification. From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 07:27:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQNiY-0003NZ-AD for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 07:27:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03531 for ; Fri, 14 Oct 2005 07:27:13 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQNtF-00009p-A5 for forces-archive@IETF.ORG; Fri, 14 Oct 2005 07:38:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0110FAD4@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 7:27:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88002437 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 07:26:52 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 07:26:52 -0400 Received: from [71.254.23.91] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12661438; Fri, 14 Oct 2005 05:26:19 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <044f01c5cfdc$ab642930$22646e0a@china.huawei.com> <6.2.1.2.0.20051013085739.02f92610@localhost> <00ae01c5d08e$752b42b0$22646e0a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051014072243.0313dc48@localhost> Date: Fri, 14 Oct 2005 07:26:47 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: ForCES Intra-NE routing mechanism Comments: To: Xiaoyi Guo To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00ae01c5d08e$752b42b0$22646e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 I follow your reasoning. I believe that initially the intra-NE links between FEs can be handled just like any other next-hop. The next-hop handling has to allow for a variety of media, so it should support whatever interconnect media is used. We can later consider several enhancements. We could improve the behavior by supporting meta-data on such links for some media. We could also improve the ability to multicast information by adding a layer of indirection so that all the FEs would see the same external next hop, rather than each FE being sent a different next hop where some see an external next hop and some see an internal next hop. One aspect here is that I think we should focus first on those LFBs that we must have, with a structure that points out which ones we would like to have. I am going to try to get a draft together before the deadline (Monday) that gives us a starting point [It was politely pointed out to me that if I think this is important I should "send text"]. Yours, Joel M. Halpern At 03:11 AM 10/14/2005, Xiaoyi Guo wrote: >hi, Joel. > >Best Regards! >Xiaoyi . > >----- Original Message ----- >From: "Joel M. Halpern" > >I am not sure I follow this discussion. > > 1) The CE can use any algorithm it likes to calculate paths. (That > applies > > both to intra-NE paths and to normal routing. ForCES does not care what > > path computation algorithm is used by the CE.) > > >Yes, you are right. ForCES does not care the algorithm , but i think we >can find a better algorithm for Intra-NE. >So I prefer a implement for it. > > > 2) I don't see the value in creating a new kind of forwarding table. For > > each FE, the forwarding table it is given ought to translate an IP prefix > > into a next hop, and the next hop into an egress port. You seem to be > > trying to add a third layer of mapping. The benefit I can see for such a > > thing might be that it could reduce slightly the differences in the tables > > across the FEs. However, I would be really unhappy at mandating such an > > architecture. > > >I think i can understand your comments and your thoughts. So i will give >more information about this mechanism. >if one NE include many FEs , there exist many paths cross the Intra-NE. >Let's suppose one of the paths >cross many FEs such as 10 FEs, but only the two edge FEs have the >connection to other routers, the other 8 FEs are >intra-FEs. I think they don't need the information of outside routers , >even they can be configured with private ip addr. >So these 8 FE just have the intra- fowarding table as i metioned . That >the reason why i suggest this multi-hop forwarding mechanism. From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 08:47:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOxw-0002j4-K3 for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 08:47:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07576 for ; Fri, 14 Oct 2005 08:47:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQP8b-0002Dy-5y for forces-archive@IETF.ORG; Fri, 14 Oct 2005 08:58:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0110FB9A@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 8:47:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88010640 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 08:47:08 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 08:47:08 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9ECjlXK039114; Fri, 14 Oct 2005 05:45:47 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0709657B@orsmsx408> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129293990.7115.28.camel@localhost.localdomain> Date: Fri, 14 Oct 2005 08:46:30 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated text on HA section Comments: To: Robert Haas , "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0709657B@orsmsx408> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Robert, Can you please comment on this text so we can close it? Hormuzd - I dont see any text on multicast IDs. cheers, jamal On Fri, 2005-14-10 at 00:10 -0700, Khosravi, Hormuzd M wrote: > HA section text attached. Incorporated latest feedback. > > Jamal, pls feel free to make any more changes if need be, > > > > Thanks > > Hormuzd > > > > > ______________________________________________________________________ > From: Khosravi, Hormuzd M > Sent: Wednesday, October 12, 2005 2:39 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: updated text on HA section > > > > > The text is attached as per the protocol team discussions. > > > > > > regards > > > Hormuzd > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 10:06:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQD4-00051G-LI for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 10:06:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12361 for ; Fri, 14 Oct 2005 10:06:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQNn-0004Sz-Rr for forces-archive@IETF.ORG; Fri, 14 Oct 2005 10:18:04 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0110FD9F@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 10:06:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88015705 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 10:06:55 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 10:06:54 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9EE68XK039519 for ; Fri, 14 Oct 2005 07:06:09 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-H9rjDFz8e5K7+Y71hlGR" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129298812.6407.3.camel@localhost.localdomain> Date: Fri, 14 Oct 2005 10:06:52 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: section 6.2.1 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 --=-H9rjDFz8e5K7+Y71hlGR Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks to Weiming for the content. Weiming and other people please review to make sure things are fine. The major thing that i changed from what appears to have been the original discussion was the "FE Heartbeat Interval" section. It seems to make more sense to me to describe it as above. cheers, jamal --=-H9rjDFz8e5K7+Y71hlGR Content-Disposition: attachment; filename=sec621.txt Content-Type: text/plain; name=sec621.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 6.2.1. FE Protocol LFB The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The FE Protocol LFB Class ID is assigned the value 0x1. The FE Protocol LFB Instance ID is assigned the value 0x1. There MAY be one and only one instance of the FE Protocol LFB in an FE. The values of the attributes in the FE Protocol LFB have pre-defined default values that are specified here. Unless explicit changes are made to these values using Config messages from the CE, these default values MUST be used for the operation of the protocol. The formal definition of the FE Protocol LFB can be found in Appendix C The FE Protocol LFB consists of the following elements: o FE Protocol events that can be subscribed/unsubscribed: * FE heartbeat o FE Protocol capabilities (read-only): * Supported ForCES protocol version(s) by the FE * Supported ForCES FE model(s) by the FE * Some TML capability description(s) o FE Protocol attributes (can be read and set): * Current version of the ForCES protocol * Current version of the FE model * FE unicast ID * FE multicast ID(s) (list) * CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat Dead Interval (CE HDI)' as described below defines Doria (Ed.), et al. Expires February 2, 2006 [Page 42] Internet-Draft ForCES August 2005 the operating parameters for the FE to check the CE liveness. The policy values with meanings are listed as below: 0(default) - This policy specifies that CE will send a Heartbeat Message to FE whenever CE reaches a time interval within which no other PL messages were sent from CE to FE; refer to Section 3.3.2 for details. The HDI attribute as described below is tied to this policy. If the FE has not received any PL messages within CE HDI period it declares the connectivity lost. The CE independently chooses the time interval to send the Heartbeat messages to FE - care must be exercised to ensure the CE->FE HB interval is smaller than the CE HDI assigned. 1 - The CE will not generate any HB messages. This actually means CE does not want the FE to check the CE liveness. Others - reserved. CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses to check the CE liveness. If FE has not received any messages from CE within this time interval, FE deduces lost connectivity which implies that the CE is dead or the association to the CE is lost. Default value 900ms. * FE heartbeat policy - This policy, along with the parameter 'FE Heartbeat Interval (FE HI)', define the operating parameters for how the FE should behave so that the CE can deduce its liveliness. The policy values and the meanings are: 0(default) - The FE should not generate any Heartbeat messages. In this scenario, the CE is responsible for checking FE liveness by setting the PL header ACK flag to AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat Request Message. Refer to Section 6.9 and Section 3.3.2 for details. 1 - This policy specifies that FE must actively send a Heartbeat Message if it reaches the time interval assigned by the FE HI as long as no no other messages were sent from FE to CE during that interval as described in Section 3.3.2. Others - Reserved. * FE Heartbeat Interval (FE HI) - The time interval the FE should use to send HB as long as no other messages were sent from FE to CE during that interval as described in Section 3.3.2. Doria (Ed.), et al. Expires February 2, 2006 [Page 43] Internet-Draft ForCES August 2005 * Primary CE * FE restart policy - This specifies the behavior of the FE during a FE restart. The restart may be from a FE failure or other reasons that have made FE down and then need to restart. The values are defined as below: 0(default)- just restart the FE from scratch. In this case, the FE should start from pre-association phase definitely. 1 - restart the FE from an intermediate state. In this case, the FE itself decides from which state it restarts. For example, if the FE still keeps enough infomation of pre- association phase after some failure, it then has the right just to start from post-associatin phase with this policy case. Others - Reserved * CE failover policy - This specifies the behavior of the FE during a CE failure and restart time interval, or when the FE loses the CE association. A timeout parameter is associated with this attribute. (The default value for the timeout is set to 30 seconds). Values of this policy are defined as below: 0(default) - The FE should continue running and do what it can even without an associated CE. This basically makes the FE support CE Graceful restart. Note that if the CE still has not been restarted or hasn't been associated back to the FE, after a time interval specified by the timeout parameter, the FE will go down completely. 1 - FE should go down to stop functioning immediately. 2 - FE should go inactive to temporarily stop functioning. If the CE still has not been restarted after a time interval of specified by the timeout parameter, the FE will go down completely. Others - Reserved --=-H9rjDFz8e5K7+Y71hlGR-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 11:28:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRUK-0002qy-Dq for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 11:28:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23885 for ; Fri, 14 Oct 2005 11:28:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQRex-0000sP-Ax for forces-archive@IETF.ORG; Fri, 14 Oct 2005 11:39:58 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.01110044@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 11:28:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88023952 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 11:28:34 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 11:28:33 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.2105028806; Sat, 15 Oct 2005 00:09:11 +0800 (CST) References: <1129298812.6407.3.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <008a01c5d19d$2c570be0$1f12fea9@wwm1> Date: Sat, 15 Oct 2005 23:29:02 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: section 6.2.1 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.0 (++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Jamal, This looks quite good to me. Some small suggestions and a modification for CE failover policy is as below. cheers, Weiming 6.2.1. FE Protocol LFB The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The FE Protocol LFB Class ID is assigned the value 0x1. The FE Protocol LFB Instance ID is assigned the value 0x1. There MAY be one and only one instance of the FE Protocol LFB in an FE. The values of the attributes in the FE Protocol LFB have pre-defined default values that are specified here. Unless explicit changes are made to these values using Config messages from the CE, these default values MUST be used for the operation of the protocol. The formal definition of the FE Protocol LFB can be found in Appendix C !-- a full stop please:) The FE Protocol LFB consists of the following elements: o FE Protocol events that can be subscribed/unsubscribed: * FE heartbeat !-- I don't think our current HB mechanism has treated HB as an event. We can leave the FE Protocol event title here, but may only mention that 'Currently no FE Protocol events have been defined.' o FE Protocol capabilities (read-only): * Supported ForCES protocol version(s) by the FE * Supported ForCES FE model(s) by the FE * Some TML capability description(s) !-- it's really a blank that need to fill out here. o FE Protocol attributes (can be read and set): * Current version of the ForCES protocol * Current version of the FE model * FE unicast ID * FE multicast ID(s) (list) !-- I think we need to input some more information here. * CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat Dead Interval (CE HDI)' as described below defines the operating parameters for the FE to check the CE liveness. The policy values with meanings are listed as below: 0(default) - This policy specifies that CE will send a Heartbeat Message to FE whenever CE reaches a time interval within which no other PL messages were sent from CE to FE; refer to Section 3.3.2 for details. The HDI attribute as !-- may be CE HDI instead of only HDI be more consistent. described below is tied to this policy. If the FE has not received any PL messages within CE HDI period it declares the connectivity lost. The CE independently chooses the time interval to send the Heartbeat messages to FE - care must be exercised to ensure the CE->FE HB interval is smaller than the CE HDI assigned. 1 - The CE will not generate any HB messages. This actually means CE does not want the FE to check the CE liveness. Others - reserved. CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses to check the CE liveness. If FE has not received any messages from CE within this time interval, FE deduces lost connectivity which implies that the CE is dead or the association to the CE is lost. Default value 900ms. !-- this paragraph should be aligned with the list symbol *. The default value 900ms is really a point for more discussion. I suggest a much larger value for this, such as 9s(second) or even more. Just considering when a TCP lost connection and then re-established the connection. We may better choose a value that can generally cover the simplist TCP case. * FE heartbeat policy - This policy, along with the parameter 'FE Heartbeat Interval (FE HI)', define the operating parameters for how the FE should behave so that the CE can deduce its liveliness. The policy values and the meanings are: 0(default) - The FE should not generate any Heartbeat messages. In this scenario, the CE is responsible for checking FE liveness by setting the PL header ACK flag to !-- may be better to say "by setting the PL header ACK flag of Heartbeat Messages it sends to 'AlwaysACK'." AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat Request Message. Refer to Section 6.9 and Section 3.3.2 for details. 1 - This policy specifies that FE must actively send a Heartbeat Message if it reaches the time interval assigned by the FE HI as long as no no other messages were sent from FE to CE during that interval as described in Section 3.3.2. !-- I haven't seen more information said in Section 3.3.2 for reference. Others - Reserved. * FE Heartbeat Interval (FE HI) - The time interval the FE should use to send HB as long as no other messages were sent from FE to CE during that interval as described in Section 3.3.2. !-- same as above. Section 3.3.2 needs to be riched than. May add "The default value for FE HI is 300ms.". * Primary CE !-- is it a Primary CE ID, Robert? * FE restart policy - This specifies the behavior of the FE during a FE restart. The restart may be from a FE failure or other reasons that have made FE down and then need to restart. The values are defined as below: 0(default)- just restart the FE from scratch. In this case, the FE should start from pre-association phase definitely. 1 - restart the FE from an intermediate state. In this case, the FE itself decides from which state it restarts. For example, if the FE still keeps enough infomation of pre- association phase after some failure, it then has the right just to start from post-associatin phase with this policy case. Others - Reserved * CE failover policy - This specifies the behavior of the FE during a CE failure and restart time interval, or when the FE loses the CE association. A timeout parameter is associated with this attribute. (The default value for the timeout is set to 30 seconds). Values of this policy are defined as below: 0(default) - The FE should continue running and do what it can even without an associated CE. This basically makes the FE support CE Graceful restart. Note that if the CE still has not been restarted or hasn't been associated back to the FE, after a time interval specified by the timeout parameter, the FE will go down completely. 1 - FE should go down to stop functioning immediately. 2 - FE should go inactive to temporarily stop functioning. If the CE still has not been restarted after a time interval of specified by the timeout parameter, the FE will go down completely. Others - Reserved !-- Jamal, after re-reading the CE failover policy part, I hope to do the modification as below. Could you help to modify more and then put it in? * CE failover policy - This specifies the behavior of the FE during a CE failure and restart time interval, or when the FE loses the CE association. The CE Timeout Interval (CE TI) as defined below is associated with this attribute. Values of this policy are defined as below: 0(default) - The FE should continue running and do what it can even without an associated CE. This basically makes the FE support CE Graceful restart. Note that if the CE still has not been restarted or the FE hasn't been associated back to a new CE after it reaches the CE Timeout Interval (CE TI) , the FE will go down completely. 1 - FE should go down to stop functioning immediately. 2 - FE should go inactive to temporarily stop functioning. If the CE still has not been restarted after a time interval of specified by the timeout parameter, the FE will go down completely. Others - Reserved * CE Timeout Interval (CE TI) - The time interval along with the CE failover policy case '0' for the FE to decide if it should go down compeltely or not. The default value is set to 30 seconds. Note that the CE TI value shoud be set larger than the CE Heartbeat Dead Interval (CE HDI) that is used for the FE to judge CE dead, as described above. Usually, the more time of CE TI than CE HDI is used for the FE to associate to a new CE for the High Availability consideration. See Section 8 for more details. ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Friday, October 14, 2005 10:06 PM Subject: section 6.2.1 > > Thanks to Weiming for the content. > > Weiming and other people please review to make sure things are fine. > The major thing that i changed from what appears to have been the > original discussion was the "FE Heartbeat Interval" section. It seems to > make more sense to me to describe it as above. > > cheers, > jamal > From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 13:15:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQT9q-0004CZ-H1 for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 13:15:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01263 for ; Fri, 14 Oct 2005 13:15:45 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQTKa-0004K1-8q for forces-archive@IETF.ORG; Fri, 14 Oct 2005 13:26:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.01110404@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 13:15:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88032250 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 13:15:39 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 13:15:39 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9EHFdTd027912; Fri, 14 Oct 2005 17:15:39 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9EHFVkj004687; Fri, 14 Oct 2005 17:15:39 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101410153917600 ; Fri, 14 Oct 2005 10:15:39 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 10:15:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] updated text on HA section Thread-Index: AcXQvWeTOb1spO5xSbmrXMJaZpVeUQAJWX+g X-OriginalArrivalTime: 14 Oct 2005 17:15:38.0909 (UTC) FILETIME=[E5F40CD0:01C5D0E2] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E070969CC@orsmsx408> Date: Fri, 14 Oct 2005 10:15:35 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: updated text on HA section Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Jamal, Pls read the last para, it has the text on multicast IDs. If you would like to add something more that I missed, feel free. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, October 14, 2005 5:47 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] updated text on HA section Robert, Can you please comment on this text so we can close it? Hormuzd - I dont see any text on multicast IDs. cheers, jamal On Fri, 2005-14-10 at 00:10 -0700, Khosravi, Hormuzd M wrote: > HA section text attached. Incorporated latest feedback.=20 >=20 > Jamal, pls feel free to make any more changes if need be, >=20 > =20 >=20 > Thanks >=20 > Hormuzd=20 >=20 > =20 >=20 > =20 > ______________________________________________________________________ > From: Khosravi, Hormuzd M=20 > Sent: Wednesday, October 12, 2005 2:39 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: updated text on HA section >=20 >=20 > =20 >=20 > The text is attached as per the protocol team discussions. >=20 >=20 > =20 >=20 >=20 > regards >=20 >=20 > Hormuzd >=20 >=20 > =20 >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 13:19:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTDb-00066Y-Sh for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 13:19:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01448 for ; Fri, 14 Oct 2005 13:19:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQTOL-0004QM-1y for forces-archive@IETF.ORG; Fri, 14 Oct 2005 13:30:51 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.011103CC@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 13:19:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88032520 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 13:19:39 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 13:19:38 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9EHInXK040747; Fri, 14 Oct 2005 10:18:50 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E070969CC@orsmsx408> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129310375.6407.106.camel@localhost.localdomain> Date: Fri, 14 Oct 2005 13:19:35 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated text on HA section Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E070969CC@orsmsx408> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit On Fri, 2005-14-10 at 10:15 -0700, Khosravi, Hormuzd M wrote: > Jamal, > > Pls read the last para, it has the text on multicast IDs. > If you would like to add something more that I missed, feel free. > Ok, my bad. It looks good - but lets hear from Robert and i will make this the last thing i update. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 14:45:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUYX-00020u-F1 for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 14:45:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04687 for ; Fri, 14 Oct 2005 14:45:20 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQUjI-0006GO-4c for forces-archive@IETF.ORG; Fri, 14 Oct 2005 14:56:33 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.01110720@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 14:44:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88038772 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 14:44:02 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 14:44:02 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9EIh5XK041499; Fri, 14 Oct 2005 11:43:05 -0700 (PDT) References: <1129298812.6407.3.camel@localhost.localdomain> <008a01c5d19d$2c570be0$1f12fea9@wwm1> Content-Type: multipart/mixed; boundary="=-xjQ4Qw1+gRmayg39MyjK" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129315431.6407.115.camel@localhost.localdomain> Date: Fri, 14 Oct 2005 14:43:51 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: section 6.2.1 Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <008a01c5d19d$2c570be0$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df --=-xjQ4Qw1+gRmayg39MyjK Content-Type: text/plain Content-Transfer-Encoding: 7bit Weiming, Thanks for your efforts. I have attached the update with your comment. Please try to read it to completion. On Sat, 2005-15-10 at 23:29 +0800, Weiming Wang wrote: > Jamal, > > This looks quite good to me. Some small suggestions and a modification for CE > failover policy is as below. > > cheers, > Weiming > > 6.2.1. FE Protocol LFB > > The FE Protocol LFB is a logical entity in each FE that is used to > control the ForCES protocol. The FE Protocol LFB Class ID is > assigned the value 0x1. The FE Protocol LFB Instance ID is assigned > the value 0x1. There MAY be one and only one instance of the FE > Protocol LFB in an FE. The values of the attributes in the FE > Protocol LFB have pre-defined default values that are specified here. > Unless explicit changes are made to these values using Config > messages from the CE, these default values MUST be used for the > operation of the protocol. > > The formal definition of the FE Protocol LFB can be found in > Appendix C > !-- a full stop please:) > > The FE Protocol LFB consists of the following elements: > > o FE Protocol events that can be subscribed/unsubscribed: > > * FE heartbeat > > !-- I don't think our current HB mechanism has treated HB as an event. We can > leave the FE Protocol event title here, but may only mention that 'Currently no > FE Protocol events have been defined.' > > o FE Protocol capabilities (read-only): > > * Supported ForCES protocol version(s) by the FE > > * Supported ForCES FE model(s) by the FE > > * Some TML capability description(s) > > !-- it's really a blank that need to fill out here. I did not quiet follow what you meant here. > !-- I haven't seen more information said in Section 3.3.2 for reference. > 3.3.2 is the section which refers to the traffic sensitive HBs. It seems relevant. Let me know if that is insufficient. > !-- same as above. Section 3.3.2 needs to be riched than. May add "The default > value for FE HI is 300ms.". > I made it 500ms. > * Primary CE > > !-- is it a Primary CE ID, Robert? > Yes, this is important - if Robert doesnt respond i will make it as you state above. > !-- Jamal, after re-reading the CE failover policy part, I hope to do the > modification as below. Could you help to modify more and then put it in? > Please take a look at the text in there now; theres some small mod. Let me know if it is sufficient. cheers, jamal --=-xjQ4Qw1+gRmayg39MyjK Content-Disposition: attachment; filename=sec621.txt Content-Type: text/plain; name=sec621.txt; charset=utf-8 Content-Transfer-Encoding: 7bit 6.2.1. FE Protocol LFB The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The FE Protocol LFB Class ID is assigned the value 0x1. The FE Protocol LFB Instance ID is assigned the value 0x1. There MAY be one and only one instance of the FE Protocol LFB in an FE. The values of the attributes in the FE Protocol LFB have pre-defined default values that are specified here. Unless explicit changes are made to these values using Config messages from the CE, these default values MUST be used for the operation of the protocol. The formal definition of the FE Protocol LFB can be found in Appendix C The FE Protocol LFB consists of the following elements: o FE Protocol capabilities (read-only): * Supported ForCES protocol version(s) by the FE * Supported ForCES FE model(s) by the FE * Any TML capability description(s) o FE Protocol attributes (can be read and set): * Current version of the ForCES protocol * Current version of the FE model * FE unicast ID * FE multicast ID(s) list - this is a list of multicast IDs that the FE belongs to. These IDs are configured by the CE. CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat Dead Interval (CE HDI)' as described below defines the operating parameters for the FE to check the CE liveness. The policy values with meanings are listed as below: Doria (Ed.), et al. Expires February 2, 2006 [Page 42] Internet-Draft ForCES August 2005 0(default) - This policy specifies that CE will send a Heartbeat Message to FE whenever CE reaches a time interval within which no other PL messages were sent from CE to FE; refer to Section 3.3.2 for details. The CE HDI attribute as described below is tied to this policy. If the FE has not received any PL messages within CE HDI period it declares the connectivity lost. The CE independently chooses the time interval to send the Heartbeat messages to FE - care must be exercised to ensure the CE->FE HB interval is smaller than the CE HDI assigned. 1 - The CE will not generate any HB messages. This actually means CE does not want the FE to check the CE liveness. Others - reserved. CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses to check the CE liveness. If FE has not received any messages from CE within this time interval, FE deduces lost connectivity which implies that the CE is dead or the association to the CE is lost. Default value 30 s. * FE heartbeat policy - This policy, along with the parameter 'FE Heartbeat Interval (FE HI)', define the operating parameters for how the FE should behave so that the CE can deduce its liveliness. The policy values and the meanings are: 0(default) - The FE should not generate any Heartbeat messages. In this scenario, the CE is responsible for checking FE liveness by setting the PL header ACK flag of the message it sends to AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat Request Message. Refer to Section 6.9 and Section 3.3.2 for details. 1 - This policy specifies that FE must actively send a Heartbeat Message if it reaches the time interval assigned by the FE HI as long as no other messages were sent from FE to CE during that interval as described in Section 3.3.2. Others - Reserved. * FE Heartbeat Interval (FE HI) - The time interval the FE should use to send HB as long as no other messages were sent from FE to CE during that interval as described in Section 3.3.2. The deafult value for a FE HI is 500ms. * Primary CE Doria (Ed.), et al. Expires February 2, 2006 [Page 43] Internet-Draft ForCES August 2005 * FE restart policy - This specifies the behavior of the FE during a FE restart. The restart may be from a FE failure or other reasons that have made FE down and then need to restart. The values are defined as below: 0(default)- just restart the FE from scratch. In this case, the FE should start from pre-association phase definitely. 1 - restart the FE from an intermediate state. In this case, the FE itself decides from which state it restarts. For example, if the FE still keeps enough infomation of pre- association phase after some failure, it then has the right just to start from post-associatin phase with this policy case. Others - Reserved * CE failover policy - This specifies the behavior of the FE during a CE failure and restart time interval, or when the FE loses the CE association. It should be noted that this policy in the case of HA only takes effect after total failure to connect to a new CE. A timeout parameter, the CE Timeout Interval (CE TI) is associated with this attribute. Values of this policy are defined as below: 0(default) - The FE should continue running and do what it can even without an associated CE. This basically makes the FE support CE Graceful restart. Note that if the CE still has not been restarted or hasn't been associated back to the FE, after the CE TI has expired, the FE will go operationally down. 1 - FE should go down to stop functioning immediately. 2 - FE should go inactive to temporarily stop functioning. If the CE still has not been restarted after a time interval of specified by the CE TI, the FE will go down completely. Others - Reserved * CE Timeout Interval (CE TI) - The time interval associated with the CE failover policy case '0' and '2'. The default value is set to 300 seconds. Note that it is advisable to set the CE TI value much higher than than the CE Heartbeat Dead Interval (CE HDI) since the effect of expiring this parameter is devastating to the operation of the FE. Doria (Ed.), et al. Expires February 2, 2006 [Page 44] Internet-Draft ForCES August 2005 --=-xjQ4Qw1+gRmayg39MyjK-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 14 23:09:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQcQQ-0005kr-2D for forces-archive@megatron.ietf.org; Fri, 14 Oct 2005 23:09:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13029 for ; Fri, 14 Oct 2005 23:09:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQcb8-0006qL-IH for forces-archive@IETF.ORG; Fri, 14 Oct 2005 23:20:46 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.011116BB@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 23:09:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88068876 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 23:09:24 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 23:09:21 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.2105028806; Sat, 15 Oct 2005 11:50:00 +0800 (CST) References: <1129298812.6407.3.camel@localhost.localdomain> <008a01c5d19d$2c570be0$1f12fea9@wwm1> <1129315431.6407.115.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <001c01c5d135$def383e0$1f12fea9@wwm1> Date: Sat, 15 Oct 2005 11:09:33 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: section 6.2.1 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Jamal, Also thanks for your great efforts. Some small editorial changes as marked inline. * FE multicast ID(s) list - this is a list of multicast IDs that the FE belongs to. These IDs are configured by the CE. CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat Dead Interval (CE HDI)' as described below defines the operating parameters for the FE to check the CE liveness. The policy values with meanings are listed as below: 0(default) - This policy specifies that CE will send a Heartbeat Message to FE whenever CE reaches a time interval within which no other PL messages were sent from CE to FE; refer to Section 3.3.2 for details. The CE HDI attribute as described below is tied to this policy. If the FE has not received any PL messages within CE HDI period it declares the connectivity lost. The CE independently chooses the time interval to send the Heartbeat messages to FE - care must be exercised to ensure the CE->FE HB interval is smaller than the CE HDI assigned. 1 - The CE will not generate any HB messages. This actually means CE does not want the FE to check the CE liveness. Others - reserved. CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses to check the CE liveness. If FE has not received any messages from CE within this time interval, FE deduces lost connectivity which implies that the CE is dead or the association to the CE is lost. Default value 30 s. !-- Jamal, please check the xml on the above paragraphs. I think the above paragraphs are not rightly listed. ...... * CE Timeout Interval (CE TI) - The time interval associated with the CE failover policy case '0' and '2'. The default value is set to 300 seconds. Note that it is advisable to set the CE TI value much higher than than the CE Heartbeat Dead Interval (CE !-- typo: ^^^^ HDI) since the effect of expiring this parameter is devastating to the operation of the FE. ----- Original Message ----- From: "Jamal Hadi Salim" > Weiming, > > Thanks for your efforts. > I have attached the update with your comment. Please try to read it to > completion. > From HelenNorman@lesmeufs.net Sat Oct 15 05:33:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQiQB-0008De-Dn for forces-archive@megatron.ietf.org; Sat, 15 Oct 2005 05:33:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00445 for ; Sat, 15 Oct 2005 05:33:38 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQib2-0007FH-JV for forces-archive@ietf.org; Sat, 15 Oct 2005 05:44:59 -0400 Received: from p5095-ipad412marunouchi.tokyo.ocn.ne.jp ([222.146.197.95]) by mx2.foretec.com with smtp (Exim 4.24) id 1EQiQ0-0004zv-TU for forces-archive@ietf.org; Sat, 15 Oct 2005 05:33:33 -0400 Received: from mvRy@localhost by vgZ7.int (8.11.6/8.11.6); Sat, 15 Oct 2005 04:05:03 -0700 Message-ID: From: "Terri Jernigan" Reply-To: "Terri Jernigan" To: forces-archive@ietf.org Subject: Top of the Line Microsoft Software at Guaranteed L0W PRlCES Date: Sat, 15 Oct 2005 13:08:03 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: HelenNorman@lesmeufs.net Content-Type: multipart/mixed; boundary="--Jst5PvGOTJ0Kz8sQX" X-Spam-Score: 0.2 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 qXv ----Jst5PvGOTJ0Kz8sQX Content-Type: text/html; Content-Transfer-Encoding: quoted-printable T
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

  

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Ad= obe Photoshop 9.0
 3 Wi= ndows XP Pro
 4 Adobe= Acrobat 7 Pro
 5 Flash= MX 2004
 6 Corel Dr= aw 12
 7 Norton Antiv= irus 2005
 <= font face=3DVerdana size=3D1>8 Windows= 2003 Server
 9 Alias= Maya 6 Wavefrt
 10 = Adobe Illustrator 11
  See more by this manufacturer
   Microsoft
  = Symantec
   Adobe
  Custom= ers also bought
  these other items...

Micro= soft Office Professional Edition *2003*
Microsoft

=
Choose:
 

You Save:



Availability: Available for INSTANT down= load!
Coupon Code: dOggH8
 

Sales Rank: #1
System requirements  |  Other Versions
Date= Coupon Expires: August 31st, 2005
Av= erage Customer Review:3D"5 Based on 11414 reviews. Write a review.

=
List Price:$499.00
Price:$69.99
$429.01 (86%)

Adobe Photoshop CS2 V = 9.0
Adobe

Choose:<= td width=3D126>
 

<= td height=3D18 width=3D11>
List Price:$599.00
Price:<= b class=3Dprice>$69.99
You Save:$529.01 (90%)



Av= ailability: Available for INSTANT download!
Coupon Code: MZ= Pfd
 

Sales Rank: #2
<= /span>System requir= ements  |  Other Versions=
Date Coupon Expires: August 31st= , 2005
Average Customer Review:3D"5 Based on 194469 reviews. Write a rev= iew.

Microsoft Windows XP Professional or L= onghorn Edition
Microsoft<= br>

<= td vAlign=3Dtop noWrap>
Choose:
 

 List Price:$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
<= b>Coupon Code: OTqRhSBU
 

= Sales Rank: #3
System requirements  |  Other Versions
Date Coupon = Expires: August 31st, 2005
Average Cu= stomer Review:3D"5 Based on 12765 reviews. Write a review.

Adobe Acrobat P= rofessional V 7.0
Adobe

Choose:
 

<= a href=3Dhttp://studentoem.net/?y>

List Price:<= /b>$499.00
Price:$69.99
You Save:$429.01 (85%)



= Availability: Available for INSTANT download!
Coupon Code:<= /b> BkUmB
 

Sales Rank: #4=
System = requirements  |  Other Ve= rsions
Date Coupon Expires: Augus= t 31st, 2005
Average Customer Review:= 3D"5 Based on 19475 reviews. Write = a review.

----Jst5PvGOTJ0Kz8sQX-- From StanShaw@breconjazz2004.co.uk Sat Oct 15 19:47:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQvk8-0001NG-Qb for forces-archive@megatron.ietf.org; Sat, 15 Oct 2005 19:47:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02970 for ; Sat, 15 Oct 2005 19:47:06 -0400 (EDT) Received: from g74249.upc-g.chello.nl ([80.57.74.249]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQvv8-0007wx-PN for forces-archive@ietf.org; Sat, 15 Oct 2005 19:58:35 -0400 Received: from 4ve@localhost by Fc0.int (8.11.6/8.11.6); Sat, 15 Oct 2005 23:42:59 -0100 Message-ID: From: "Lily Moran" Reply-To: "Lily Moran" To: forces-archive@ietf.org Cc: sale@ietf.org Subject: Out of this WoRLD $aving$ on all Windows titles Date: Sat, 15 Oct 2005 20:35:59 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: StanShaw@breconjazz2004.co.uk Content-Type: multipart/mixed; boundary="--lKjJUWBG3IgMJjz" X-Spam-Score: 2.8 (++) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb QkbS ----lKjJUWBG3IgMJjz Content-Type: text/html; Content-Transfer-Encoding: quoted-printable q
Opt-in Email Special Offer   = ;  unsubscribe me
<= /tr>
SEARCH

TOP 10 NEW TITLES

  

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Ad= obe Photoshop 9.0
 3 Wi= ndows XP Pro
 4 Adobe= Acrobat 7 Pro
 5 Flash= MX 2004
 6 Corel Dr= aw 12
 7 Norton Antiv= irus 2005
 <= font face=3DVerdana size=3D1>8 Windows= 2003 Server
 9 Alias= Maya 6 Wavefrt
 10 = Adobe Illustrator 11
  See more by this manufacturer
   Microsoft
  = Symantec
   Adobe
  Custom= ers also bought
  these other items...

Micro= soft Office Professional Edition *2003*
Microsoft

= <= tr>
Choose:
 

You Save:



Availability: Available for INSTANT down= load!
Coupon Code: 3gZ7b
 

Sales Rank: #1
System requirements  |  Other Versions
Date= Coupon Expires: August 31st, 2005
Av= erage Customer Review:3D"5 Based on 155649 reviews. Write a review.

<= table border=3D0 cellpadding=3D0 cellspacing=3D0 style=3D"border-collapse:= collapse" bordercolor=3D#111111 width=3D100% id=3DAutoNumber1 height=3D55= >
List Price:$499.00
Price:$69.99
$429.01 (86%)

Adobe Photoshop CS2 V= 9.0
Adobe<= /a>

Choose:=
 

=
List Price:$599.00
Price:= $69.99
You Save:$529.01 (90%)



Av= ailability: Available for INSTANT download!
Coupon Code: zb= Whtof
 

Sales Rank: #2
= System requ= irements  |  Other Versio= ns
Date Coupon Expires: August 31= st, 2005
Average Customer Review: Based on 17389 reviews. Write a revi= ew.

Microsoft Windows XP Professional or Lo= nghorn Edition
Microsoft

Choose:
 

=

List Price:$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
<= b>Coupon Code: pneI0bpkU
 

Sales Rank: #3
System requirements  |  Other Versions
Date Coupon= Expires: August 31st, 2005
Average C= ustomer Review:3D"5 Based on 147434 reviews. Write a review.

<= /td>

Adobe Acrobat= Professional V 7.0
Adobe<= br>

<= td vAlign=3Dtop noWrap>
Choose:
 

List Pric= e:$499.00
Price:<= /b>$69.99
You Save:$429.01 (85%)


Availability: Available for INSTANT download!
Coupon Code= : CByuHeVe4
 

Sales Rank:<= /b> #4
S= ystem requirements  |  Ot= her Versions
Date Coupon Expires:= August 31st, 2005
Average Customer Revie= w:3D"5 Based on 131735 reviews. Write a review.

----lKjJUWBG3IgMJjz-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 16 16:16:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EREw2-0000Zs-UA for forces-archive@megatron.ietf.org; Sun, 16 Oct 2005 16:16:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20697 for ; Sun, 16 Oct 2005 16:16:36 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERF76-0004Of-Gj for forces-archive@IETF.ORG; Sun, 16 Oct 2005 16:28:17 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.011127BA@cherry.ease.lsoft.com>; 16 Oct 2005 16:16:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88163210 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 16 Oct 2005 16:16:14 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 16 Oct 2005 16:16:14 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9GKEoXK057598; Sun, 16 Oct 2005 13:14:51 -0700 (PDT) References: <1129298812.6407.3.camel@localhost.localdomain> <008a01c5d19d$2c570be0$1f12fea9@wwm1> <1129315431.6407.115.camel@localhost.localdomain> <001c01c5d135$def383e0$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129493765.6445.64.camel@localhost.localdomain> Date: Sun, 16 Oct 2005 16:16:05 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: section 6.2.1 Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <001c01c5d135$def383e0$1f12fea9@wwm1> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Hi Weiming, On Sat, 2005-15-10 at 11:09 +0800, Weiming Wang wrote: \ > CE Heartbeat Dead Interval (CE HDI) - The time interval the > FE uses to check the CE liveness. If FE has not received > any messages from CE within this time interval, FE deduces > lost connectivity which implies that the CE is dead or the > association to the CE is lost. Default value 30 s. > > !-- Jamal, please check the xml on the above paragraphs. I think the above > paragraphs are not rightly listed. > Good catch. Fixed. > ...... > > * CE Timeout Interval (CE TI) - The time interval associated with > the CE failover policy case '0' and '2'. The default value is > set to 300 seconds. Note that it is advisable to set the CE TI > value much higher than than the CE Heartbeat Dead Interval (CE > !-- typo: ^^^^ I am not sure i followed what you meant here. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 16 16:39:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERFHp-0007dl-MN for forces-archive@megatron.ietf.org; Sun, 16 Oct 2005 16:39:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21794 for ; Sun, 16 Oct 2005 16:39:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERFSo-0004z9-NZ for forces-archive@IETF.ORG; Sun, 16 Oct 2005 16:50:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.011128E2@cherry.ease.lsoft.com>; 16 Oct 2005 16:39:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88164305 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 16 Oct 2005 16:39:02 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 16 Oct 2005 16:39:01 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9GKbhXK057711 for ; Sun, 16 Oct 2005 13:37:44 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129495139.6445.82.camel@localhost.localdomain> Date: Sun, 16 Oct 2005 16:38:59 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Section 6.2.2, protocol scenarios etc. To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Folks, Section 6.2.2 is out of sync with both reality and the Model. The model itself has still incomplete in regards to the neighbor info IMO; there are smaller resolvable issues like missing events etc. This is gonna hold any attempts to go last call if not resolved. There are also issues which held me back in working on the protocol scenarios section. I dont remember the discussions earlier, but did we agree to explicitly turn on/off FEStatus to activate/deactivate the FE? There is impedance mismatch between FEObject in protocol and model as well as in the protocol scenarios. We need to resolve this. Please comment - i cant make progress otherwise. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 16 19:25:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERHsy-0003qL-7n for forces-archive@megatron.ietf.org; Sun, 16 Oct 2005 19:25:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02259 for ; Sun, 16 Oct 2005 19:25:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERI4A-0001Ei-RU for forces-archive@IETF.ORG; Sun, 16 Oct 2005 19:37:24 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.01112E2B@cherry.ease.lsoft.com>; 16 Oct 2005 19:25:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88171413 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 16 Oct 2005 19:25:12 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 16 Oct 2005 19:25:12 -0400 Received: from [71.254.23.91] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12664943 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 16 Oct 2005 17:24:35 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051016192013.02fd5300@localhost> Date: Sun, 16 Oct 2005 19:25:11 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: LFB Library draft To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe I have submitted an Internet-draft to start the process of building a base LFB library RFC. For now it is an individual submission, since it has not been seen by the WG yet. I will be asking for it to be a WG document as soon as practical. I am including the abstract and table of contents below, to give an idea of the approach I have taken. It should appear in the repository, assuming I did not make any silly mistakes, in the near future. If anyone wants a copy sooner, just ask. Yours, Joel M. Halpern Abstract The Forwarding and Control Element Separation (ForCES) working group is defining a protocol to allow a Control Element (CE) to control the behavior of a Forwarding Element (FE). The manipulations used by this protocol operate in terms of adjustments to Logical Function Blocks (LFBs) whose structure is defined my a model RFC produced by the working group. In order to build an actual solution using this protocol, there needs to be a set of Logical Function Block definitions that can be instantiated by FEs and controlled by CEs. This document provides an initial set of such definitions. It is Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 3. Base Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 4. Connectivity LFBs . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Generic Connectivity LFB . . . . . . . . . . . . . . . . . 4 4.2. Redirect LFB . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. taggedInterface . . . . . . . . . . . . . . . . . . . . . 8 5. Packet Validation and Manipulation LFBs . . . . . . . . . . . 8 5.1. IPv4 Validator LFB . . . . . . . . . . . . . . . . . . . . 8 5.2. IPv6 Validator LFB . . . . . . . . . . . . . . . . . . . . 8 5.3. Meta-Data marker . . . . . . . . . . . . . . . . . . . . . 8 5.4. Packet Trimmer . . . . . . . . . . . . . . . . . . . . . . 9 5.5. IPv4 outbound updater . . . . . . . . . . . . . . . . . . 9 5.6. IPv6 outbound updater . . . . . . . . . . . . . . . . . . 9 5.7. Duplicator . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Classifer LFBs . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Classifier Data Types . . . . . . . . . . . . . . . . . . 9 6.2. ArbitraryClassifierLfb . . . . . . . . . . . . . . . . . . 15 6.3. LPMClassifier . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Next Hop Applicator . . . . . . . . . . . . . . . . . . . 18 7. Packet Control LFBs . . . . . . . . . . . . . . . . . . . . . 18 7.1. ARPOutRequestLFB . . . . . . . . . . . . . . . . . . . . . 19 7.2. ARPInMessageLFB . . . . . . . . . . . . . . . . . . . . . 19 7.3. ICMPLFB . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Queue and Scheduler LFBs . . . . . . . . . . . . . . . . . . . 19 8.1. Scheduler . . . . . . . . . . . . . . . . . . . . . . . . 20 8.2. Queue . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 16 20:16:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERIfY-0008OJ-Bl for forces-archive@megatron.ietf.org; Sun, 16 Oct 2005 20:16:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04436 for ; Sun, 16 Oct 2005 20:15:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERIql-0002IM-59 for forces-archive@IETF.ORG; Sun, 16 Oct 2005 20:27:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.01112D43@cherry.ease.lsoft.com>; 16 Oct 2005 20:15:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88173675 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 16 Oct 2005 20:15:56 -0400 Received: from 192.11.226.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 16 Oct 2005 20:15:55 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9H0FmLR023535; Sun, 16 Oct 2005 19:15:49 -0500 (CDT) Received: from [192.11.174.224] (furquan.lra.lucent.com [192.11.174.224]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j9H0FmO29568; Sun, 16 Oct 2005 20:15:48 -0400 (EDT) User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------090208080403050105040405" Approved-By: Furquan Ansari Message-ID: <4352ECC7.9040202@lucent.com> Date: Sun, 16 Oct 2005 20:13:59 -0400 Reply-To: Furquan Ansari Sender: Forwarding and Control Element Separation From: Furquan Ansari Subject: Discovery Draft Comments: To: internet-drafts@ietf.org To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.7 (/) X-Scan-Signature: 966811b049c4d80323826ee01e1b1ce9 This is a multi-part message in MIME format. --------------090208080403050105040405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I would like to submit the Topology Discovery Draft to the ForCES WG. Thanks, Furquan --------------090208080403050105040405 Content-Type: text/plain; name="draft-ietf-forces-discovery-00.txt" Content-Disposition: inline; filename="draft-ietf-forces-discovery-00.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail2.lucent.com id j9H0FmLR023535 Content-Transfer-Encoding: quoted-printable Furquan Ansari=20 Internet Draft Lucent Tech.=20 Document: draft-ansari-forces-discovery-01.txt Hormuzd Khosravi=20 Expires: April 15, 2006 Intel Corp.=20 Working Group: ForCES Jamal Hadi Salim=20 Znyx Networks=20 Joel M. Halpern=20 Megisto Systems=20 October 16, 2005=20 =20 =20 =20 ForCES Intra-NE Topology Discovery=20 =20 draft-ietf-forces-discovery-00.txt=20 =20 =20 Status of this Memo=20 =20 By submitting this Internet-Draft, I certify that any applicable=20 patent or other IPR claims of which I am aware have been disclosed,=20 and any of which I become aware will be disclosed, in accordance=20 with RFC 3668.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as ``work in=20 progress.''=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 =20 The list of Internet-Draft Shadow Directories can be accessed at =20 http://www.ietf.org/shadow.html.=20 =20 This Internet-Draft will expire in April 24, 2005.=20 =20 =20 Conventions used in this document =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in [RFC-2119].=20 =20 Abstract=20 =20 Ansari et al. Expires: Jan 2005 [Page 1] =0C Internet Draft ForCES Discovery July 2004=20 This document describes a mechanism for discovering inter-FE=20 topology and topology maintenance. Such a mechanism is essential for=20 all these elements in the set to behave as a single Network Element,=20 as required by the ForCES architecture as well as to perform certain=20 optimizations at the FE by making use of the topology. The discovery=20 mechanism only operates during post-association phase of ForCES=20 protocol.=20 =20 =20 Table of Contents=20 1. Definitions.......................................................23=20 2. Introduction.......................................................3=20 2.1. Motivation....................................................4=20 3. Topology Discovery Mechanism.......................................5=20 3.1. Minimum requirements..........................................6=20 3.2. Protocol Details.............................................67=20 3.2.1. Neighbor Finite State Machine...........................78=20 3.2.2. Topology Discovery and Maintenance.......................8=20 3.2.3. Full topology computation at the CE from partial=20 topologies......................................................9=20 3.3. Protocol and Message Headers................................910=20 3.3.1. TLV definitions.......................................1011=20 3.4. Inter-FE Topology Discovery Examples.......................1011=20 3.4.1. Forwarding Elements connected in a daisy chain..........12=20 3.4.2. Forwarding Elements connected in a ring.................13=20 4. Security Considerations...........................................14=20 5. References......................................................1415=20 5.1. Normative..................................................1415=20 5.2. Informative................................................1415=20 6. Authors' Addresses..............................................1415=20 7. IANA Considerations.............................................1516=20 8. Full Copyright Notice...........................................1516=20 9. Acknowledgements..................................................16=20 =20 1. Definitions=20 =20 Inter-FE topology discovery: Topology discovery relates to how the=20 FEs are interconnected with each other with respect to packet=20 forwarding. This is the complete view of the intra-NE network as=20 seen by the CE.=20 =20 Inter-FE topology maintenance: Once the inter-FE topology has been=20 discovered, it has to be continuously monitored to ensure that any=20 Ansari et al. Expires: Jan 2005 [Page 2] =0C Internet Draft ForCES Discovery July 2004=20 changes to the topology are reported to the corresponding CE. This=20 represents the steady state and final phase of the protocol.=20 =20 =20 2. Introduction=20 =20 The ForCES framework document [RFC 3746] describes how a set of=20 control elements (CEs) and forwarding elements (FEs) interact with=20 each other to form a single network element (NE). It describes the=20 ForCES post-association phase protocol working across the Fp=20 reference point between CE and FE. This document describes an=20 important aspect of the ForCES operational infrastructure- that of=20 discovering the layout of the different elements within an NE.=20 =20 =20 =20 The Inter-FE/Intra-NE topology discovery protocol module may be=20 implemented as a separate LFB on the FE. The protocol runs in an=20 ongoing discovery and maintenance mode wherein the LFB maintains=20 information about the known adjacencies per interface it is operated=20 on. Each FE simply maintains its own adjacency tables and notifies the=20 CE of any changes to the adjacency table based on the ForCES=20 notification mechanism or if the CE explicitly requests an update. It=20 is up to the CE to construct the full topology based on the information=20 received from individual FEs within the NE. Given that the CE can=20 request and the FEs should report back the topology updates using=20 ForCES protocol, it is implicit that the topology discovery and=20 maintenance operation occurs in the ForCES post-association phase.=20 =20 . =20 =20 =20 =20 The proposed discovery mechanism is required to scale to a very=20 large number of forwarding elements in the NE, with minimal impact=20 on the resources. The following list provides some of the features=20 and goals of the discovery mechanism.=20 =20 . Determine connectivity between elements=20 . React to changes in link connectivity=20 . Construct topology information from the collected partial topology=20 information=20 . Tolerant to protocol message losses=20 . Applicable to all inter-FE network topologies such as ring, mesh,=20 star etc.=20 . Cause minimal overhead=20 . Agnostic of the network interconnect technology=20 =20 =20 Ansari et al. Expires: Jan 2005 [Page 3] =0C Internet Draft ForCES Discovery July 2004=20 2.1. Motivation=20 =20 The ForCES architecture defines a network element (NE) as a single=20 managed entity made up of a collection of FEs and CEs and is=20 indistinguishable from other network elements in the network. This=20 NE model definition leads to three types of links from the network=92s= =20 perspective: internal (or intra-NE) links and external (or inter-NE)=20 links and control links. Intra-NE links are purely internal to the=20 NE and are not exposed to the external world; whereas, inter-NE (or=20 external) links are exposed to the external world and over which=20 routing adjacencies (such as OSPF, IS-IS, BGP etc.) can be formed.=20 An NE can contain FEs that have zero or more internal/external links=20 =96 e.g. in Fig. 1, FE3 has two internal links and no external links=20 while FE1 and FE2 have two internal links and one external link=20 each. Control links are those links that are used for communication=20 between the CE and FE. If the CE and FE are a single Layer 3 hop=20 apart as in Fig.1, the control link is typically a physical link=20 e.g. link A of FE1 in the figure. Control links can be logical as=20 well. It is important to note that the type definition for given for=20 a link is only logical, because a given physical link may be a=20 combination of more than one type - e.g. it could simultaneously be=20 a control link and an internal link at the same time.=20 =20 A packet entering a ForCES NE may travel multiple FEs within the NE=20 before it exits onto the output link. This requires that the packet=20 be correctly forwarded from the ingress FE to the egress FE. This=20 internal forwarding requires knowledge of the physical FE inter- connection topology so that the CE can appropriately setup internal=20 LFB tables at each FE to handle packet traversal in a sane manner.=20 We use a simple topology discovery mechanism that only operates on=20 internal links and provides the necessary routing information to=20 forward the packets from the ingress FE to the egress FE. Further,=20 the mechanism should be able to reroute around internal link=20 failures, if a path exists. This makes the NE highly available and=20 resilient.=20 =20 =20 NE 1=20 .....................................=20 . ----------------- .=20 . | CE | .=20 . ----------------- . ----------=20 . A ^ B ^ C ^ . | NE 1 |=20 . / | \ . | |=20 . / A v \ . ----------=20 . / ------- B \ . ^ ^=20 . / +->| FE3 |<-+ \ . <=3D=3D=3D=3D> / \=20 . / |C | | | \ . / \=20 . A v | ------- | v A . v v=20 Ansari et al. Expires: Jan 2005 [Page 4] =0C Internet Draft ForCES Discovery July 2004=20 . -------B | |D ------- . -------- ---------=20 . | FE1 |<-+ +->| FE2 | . | NE 2 |<---->| NE 3 |=20 . | |<--------------->| | . | | | |=20 . ------- C C ------- . -------- ---------=20 . D^ ^B .=20 .....|.......................|........ =20 | |=20 V v =20 -------- --------=20 | NE 2 |<--------------->| NE 3 |=20 | | | |=20 -------- --------=20 =20 (a) (b)=20 =20 Figure 1:(a) illustrates the internal/external links and topology=20 within a NE. (b) Shows the network topology as seen by external=20 routing protocols=20 =20 =20 3. Topology Discovery Mechanism=20 =20 Since the topology discovery protocol described here operates in the=20 ForCES post-association phase, it is independent of whether the CE=20 and the FE are a single or multiple hops (layer 2 or layer 3) apart=20 from each other. It is up to the ForCES association protocol to=20 determine how to setup the ForCES channel between the CE and FE if=20 they are multiple hops away. The topology discovery protocol is=20 expected to work on all types of media and interfaces =96 such as=20 point-to-point as well as multi-access links.=20 =20 =20 In order to keep the discovery and maintenance mechanism as simple =20 as possible, the FEs only maintain relationships with their=20 respective neighbors to determine the status of the neighbors. No=20 databases are exchanged between the neighbors. This implies that the=20 topology view for each FE is only limited to the adjacent elements.=20 This partial topology information may be reported back to the CE (or=20 queried by the CE) over the ForCES protocol using the ForCES=20 notification mechanism. Since the CE receives such information from=20 all the FEs, it can easily construct the full topology from=20 individual partial topologies reported by each FE. Once the CE=20 constructs the full topology, such information can be passed to the=20 FEs, if needed (depending on policy). The FEs may use such=20 information for dynamic intra-NE route calculation or certain other=20 optimizations.=20 =20 Topology information is needed by a lot of LFBs and associated=20 services that span multiple FEs within a NE. In the case where the=20 Ansari et al. Expires: Jan 2005 [Page 5] =0C Internet Draft ForCES Discovery July 2004=20 FE aids the CE in offloading the table updates, then it makes sense=20 for the FE to be topology aware. It is sometimes also helpful to=20 keep full topology information at the FEs for cases such as =93message= =20 snooping=94 optimizations. For example, if an FE is aware of the=20 topology, it could snoop on messages sent to other FEs (e.g.=20 broadcasts, multicasts) and update its own tables dynamically=20 without involving the CE. Another example would be FE-FE primary- backup handover scenario. With each FE being fully aware of the=20 complete topology, the backup FE can take over the responsibilities=20 of the primary without involving the CE for such a handover.=20 =20 3.1. Minimum requirements =20 =20 In order for the protocol to work as described, the following=20 assumptions are made.=20 . Each element has been configured with their respective IDs=20 (CEID, FEID)=20 . Element bindings process has already taken place. In other=20 words, the CE know all the FEs it wants to control and each FE=20 knows which CE is allowed to control it.=20 . The ForCES protocol association has already taken place between=20 the CE and the FE in question.=20 . The protocol is enabled on the required interfaces.=20 =20 Note that these are configuration requirements and are satisfied by=20 the respective managers (CEM/FEM).=20 =20 3.2. Protocol Details=20 =20 Once the ForCES protocol association has been established between a=20 CE and a given FE =96 i.e. it is in post-association phase, the CE=20 starts sending/advertising Hello/Probe messages to the FE=92s=20 neighbors such that the messages go through the given FE. In other=20 words, it looks like the given FE is generating probe messages to=20 the neighbor (except that these messages are coming from the CE over=20 the ForCES protocol first). However, this functionality of=20 generating probe messages by the CE can be offloaded to the FE=20 itself (to be more precise, to an FE LFB) =96 so that the FE can=20 originate and terminate the probe messages. This provides better=20 scalability of the CE and it=92s resources. The CE can now simply=20 query each FE=92s neighbor relationship database and register for any=20 events related to topology changes.=20 =20 All Hello/Probe messages travel a single PE hop and are not routed=20 to other elements beyond the first hop. An on-link IP multicast=20 address is used for sending all Hello packets. The packets should be=20 sent with a TTL of 255 and ignored on receipt if the TTL is not 254=20 (based on some of the recommendations from the generalized TTL=20 security mechanism to use TTL 255 rather than TTL 1). Hello packets=20 Ansari et al. Expires: Jan 2005 [Page 6] =0C Internet Draft ForCES Discovery July 2004=20 are only sent on interfaces configured for topology discovery=20 protocol operation. Further, the Hello messages will be multicast on=20 multicast capable links. Each FE topology LFB component maintains=20 the neighbor relationships as long as the Hello messages are=20 received from the neighbor. If it does not receive Hello messages=20 after a given (configured) period of time (called FE Neighbor dead=20 interval), it deletes the entry from the database and reports this=20 change to the CE in the form of an event-notification message over=20 the ForCES protocol. This ensures that the CE has the complete and=20 up-to-date information of the underlying topology of the Inter-FE=20 network.=20 =20 The Hello message contains information necessary for discovering and=20 maintaining neighbor relationships. It contains the PE ID, type of=20 protocol element (i.e. CE or FE), interval between any two messages,=20 interval for deeming a neighbor inactive, capability information=20 etc. This is, in some ways, similar to the capabilities of the OSPF=20 Hello protocol.=20 =20 On receiving the Hello messages from a neighbor, the FE responds=20 back with its own Hello message in a packet format similar to the=20 one received from the neighbor. Essentially, both sides are=20 independently sending Hello messages to each other and listing their=20 neighbor table. Also, each neighbor will see itself listed on its=20 neighbors Hello message. This ensures bi-directionality of the link=20 between any two neighbors.=20 =20 =20 The operation is concisely described by the following steps:=20 . CE activates the topology LFB/component on the FE to initialize on=20 specific ports=20 . FE topology LFB/component sends neighbor probes/hellos=20 . CE queries FE for its neighbors=20 . FE continues to send these probes afterwards (maintenance) and=20 updates asynchronously any new updates=20 =20 =20 =20 =20 3.2.1. Neighbor Finite State Machine=20 In order to obtain bi-directionality verification of the links, and=20 to make the protocol more robust, a neighbor finite state machine is=20 needed. It consists of the following three states:=20 =20 Neighbor-down: This is the initial state of the neighbor=20 conversation. It indicates that there has been no recent information=20 received from the neighbor=20 =20 Ansari et al. Expires: Jan 2005 [Page 7] =0C Internet Draft ForCES Discovery July 2004=20 Neighbor-heard: In this state, a Hello packet was recently seen from=20 the neighbor. However, bi-directional communication has not been=20 fully established with the neighbor (i.e. the PE itself was not=20 listed in the neighbor=92s Hello packet =96 which is the check for bi- directionality). All neighbors in this state (or higher) are listed=20 in the Hello packets sent from the associated interface.=20 =20 Neighbor-adjacent: In this state, the communication between the two=20 neighbors is bi-directional. This has been assured by the Hello=20 protocol operation. This state corresponds to the final steady state=20 of the protocol.=20 =20 =20 3.2.2. Topology Discovery and Maintenance=20 =20 Since the CE needs to maintain consistent and up-to-date view of the=20 inter-FE topology, it needs to obtain real-time information of the=20 status of the internal links connecting the FEs. Since the topology=20 discovery and maintenance occurs during the post-association phase,=20 we make use of the event-notification and query/response messages=20 [ForCESP] of the ForCES protocol to provide this information to the=20 CE. It is important to note that each FE only maintains partial=20 topology information obtained through neighbor relationship=20 maintenance through Hello messages. The partial topology view seen=20 by each FE is only the neighbor connectivity information. The CE has=20 to derive the complete topology view of the interconnected FEs based=20 on the partial topology information reported by each FE (or queried=20 by the CE). This ensures that that only the CE maintains all the=20 intelligence and the protocol operation on the FEs is very simple=20 and has minimal overhead. However, as mentioned above, if=20 optimizations can be performed by having the complete topology=20 information available at the FEs, the CE can push such information=20 to any FE interested in it (interest on the FE may be shown in the=20 form of policy configuration). This is an optional feature available=20 on each FE, which can be turned on or off through configuration or=20 during capability exchange negotiation at setup time. Each FE vendor=20 may decide to make use of this feature in different ways, so the=20 capability to obtain such topology information should exist.=20 =20 The periodic Hello messages maintain PE neighbor relationships.=20 Any change in the link or neighbor status causes the FE to generate=20 an asynchronous/event-driven message to the CE indicating this=20 change. The mechanism defined in [ForCESP] is used for delivering=20 event-driven messages from the FE to the CE. This involves the CE=20 subscribing to such event-driven messages from the FE. =20 =20 The CE aggregates the partial topology information received from=20 each FE and generates the inter-FE topology. With this complete=20 knowledge of the inter-FE topology, it can now make appropriate=20 Ansari et al. Expires: Jan 2005 [Page 8] =0C Internet Draft ForCES Discovery July 2004=20 updates to the LFB tables on each FE to move packets inside the NE =96= =20 from ingress FE to egress FE, assuming that the destination of the=20 packet is not the current NE itself. Any changes in the internal=20 link states (and hence the topology) requires that the CE=20 reconfigure the LFB tables on the FEs based on the most up-to-date=20 information to ensure that the packets do not end up in a black hole=20 or enter a loop. =20 =20 =20 3.2.3. Full topology computation at the CE from partial topologies=20 =20 The CE receives neighbor relationships information from each FE that=20 it uses to construct the full topology of the internal network. Each=20 FE=92s neighbor relationship table contains information regarding the=20 local element ID, local port connecting the neighbor, the neighbor=92s= =20 ID, the neighbor=92s port and any optional additional information.=20 Note that the fact that the FE already knows the neighbor=92s port=20 information implies that it received the probe/hello messages from=20 the neighbor on that port in response to the hello sent and was,=20 therefore, able to establish bi-directionality of the link. If all=20 the links in the internal network are point-to-point links, the CE=20 simply has to aggregate all the neighbor relationship tables=20 obtained from all the FEs to generate the full topology. If we=20 assume the topology to be a graph, each edge of the graph will be=20 present twice =96 essentially providing the same information from the=20 two endpoints of the graph. After deleting all the duplicate entries=20 (and thus reducing the table size by half), the CE now has accurate=20 view of the full topology. Please refer section 3.4 [Fig. 3(b)] for=20 more details.=20 =20 [Sub-section on generating full topology from partial topology=20 information for broadcast/multi-access, point-to-multipoint etc.=20 type of links] =20 =20 3.3. Protocol and Message Headers=20 =20 The protocol message consists of a fixed length header (16 bytes)=20 followed by one or more optional TLVs. The format of the message is=20 as follows.=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | Flags | Packet Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Checksum | Port ID |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | PE ID |=20 Ansari et al. Expires: Jan 2005 [Page 9] =0C Internet Draft ForCES Discovery July 2004=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | TLV-Type | TLV-Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | TLV-Value ... |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | ... |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Figure (2)=20 =20 Version: Version number of this protocol. Currently acceptable value=20 is 0x01=20 =20 Flags: These indicate whether the message is sent by a FE, (0x01) or=20 CE (0x02). More options may be defined in the future.=20 =20 Packet Length: The length of the protocol message in bytes,=20 including the header and the following TLVs.=20 =20 Checksum: 16-bit checksum for the protocol message. The checksum=20 calculation does not include the IP header.=20 =20 Port ID: This indicates the port on which this packet was sent out=20 by the sender =96 useful for topology construction. =20 =20 PE ID: This is the 32-bit identifier of the sender. It could either=20 be CE ID or FE ID, depending on the sender.=20 =20 The protocol header is followed by one or many TLVs. The following=20 TLVs types are defined:=20 =20 Hello TLV: Indicates the Hello message as exchanged by the=20 neighbors. The TLV defines the common hello parameters such as the=20 Hello Interval, Hold time, Uni-directional targeted Hellos, Sequence=20 space number, if needed etc.=20 =20 Capabilities TLV: Provides the capabilities information - TBD=20 =20 Vendor specific TLV: TBD=20 =20 =20 =20 3.3.1. TLV definitions=20 TBD=20 =20 =20 3.4. Inter-FE Topology Discovery Examples=20 =20 Ansari et al. Expires: Jan 2005 [Page 10] =0C Internet Draft ForCES Discovery July 2004=20 The following examples illustrate the topology discovery mechanism.=20 For sake of simplicity, we assume that there is only one CE per NE.=20 The FEIDs of the FEs in the topologies below are FE1, FE2, FE3, and=20 FE4. Each FE has port IDs labeled alphabetically. This is also the=20 case with the CE.=20 =20 -----------------=20 | CE |=20 -----------------=20 A ^ B ^ C ^=20 / | \=20 / A v \=20 / ------- B \=20 / +->| FE3 |<-+ \=20 / |C | | | \=20 A v | ------- | v A=20 -------B | |E -------=20 | FE1 |<-+ +->| FE2 |=20 | |<--------------->| |=20 ------- C D -------=20 E ^ D| C ^ | B=20 | | | |=20 | v | v=20 =20 =20 FE3 Control Element reachability Table=20 --------------------------------------=20 =20 CE A=20 --------------------------------------=20 =20 =20 FE3 NEIGHBOR ASSOCIATION TABLE=20 -----------------------------------------------=20 =20 B FE2 E=20 C FE1 B =20 ----------------------------------------------=20 =20 Figure 3. (a) Full mesh among FE1, FE2, and FE3=20 =20 During the element-binding phase, each FE sends out hello messages=20 with its FEID and Port ID (as outlined earlier) to all of its=20 neighbors. Since each neighboring FE also listens to such messages,=20 it receives the hello message and adds it to the neighbor=20 Ansari et al. Expires: Jan 2005 [Page 11] =0C Internet Draft ForCES Discovery July 2004=20 association table, which may look like that shown in Fig.4(a). In=20 the topology discovery phase, which is post ForCES association=20 stage, the CE queries each FE about its neighbor table. The FE=20 responds back with the partial topology information available=20 through its neighbor relationships. Both the query and the response=20 are carried by the ForCES protocol. The CE collects the partial=20 topology information from all the FEs in the NE and aggregates this=20 information to fully construct the inter-FE topology. Any changes to=20 the FE neighbor table, e.g. when a link state changes, generates a=20 trigger/update message to the CE. The new information is used to=20 recalculate the new topology and subsequently the CE takes=20 appropriate actions based on the new topology =96 such as updating the= =20 packet forwarding tables on the FEs.=20 =20 The following examples show the neighbor association tables.=20 =20 =20 3.4.1. Forwarding Elements connected in a daisy chain=20 =20 =20 --------------=20 | CE |=20 --------------=20 A ^ ^ B ^ ^ D=20 / | \ \=20 /------ | --\ -------\=20 A v A v v A v A=20 -------B -------B -------B -------=20 | FE1 |<--->| FE2 |<--->| FE3 |<--->| FE4 |=20 ------- E------- E------- D-------=20 D ^ |C D ^ |C D^ |C C^ |B=20 | | | | | | | |=20 | v | v | v | v=20 =20 =20 =20 FE1 NBR ASSOCIATION TABLE FE2 NBR ASSOCIATION TABLE=20 -------------------------------- ------------------------------=20 =20 B FE2 E E FE1 B=20 B FE3 E=20 =20 =20 FE3 NBR ASSOCIATION TABLE FE4 NBR ASSOCIATION TABLE=20 -------------------------------- -----------------------------=20 =20 B FE4 D D FE3 B=20 E FE2 B=20 =20 Ansari et al. Expires: Jan 2005 [Page 12] =0C Internet Draft ForCES Discovery July 2004=20 =20 =20 =20 CE Topology (Aggregate)View CE Topology View=20 -------------------------------- ------------------------------=20 =20 FE1 B FE2 E\ FE1 B FE2 E = =20 FE2 E FE1 B/ =3D> FE2 B FE3 E=20 FE2 B FE3 E\ FE3 B FE4 D=20 FE3 E FE2 B/ ------------------------------=20 FE3 B FE4 D\=20 FE4 D FE3 B/=20 --------------------------------=20 =20 =20 =20 Fig.3(b) Multiple FEs in a daisy chain=20 =20 =20 =20 3.4.2. Forwarding Elements connected in a ring=20 =20 =20 ^ |=20 D| v E=20 ----------- A=20 | FE1 |<-----------------------|=20 ----------- |=20 C ^ ^ B |=20 / \ |=20 | ^ / \ ^ | V A=20 B v |C v D C v D| v E ----------=20 --------- --------- D| |=20 | FE2 | | FE3 |<------------>| CE |=20 --------- --------- A | |=20 A ^ ^ E ^ B ----------=20 | \ / C ^ ^ B=20 | \ / | |=20 | D v E v | |=20 | ----------- A | |=20 | | FE4 |<----------------------| |=20 | ----------- |=20 | C | ^ B |=20 | v | |=20 | |=20 |----------------------------------------|=20 =20 =20 Ansari et al. Expires: Jan 2005 [Page 13] =0C Internet Draft ForCES Discovery July 2004=20 =20 FE1 NBR ASSOCIATION TABLE FE2 NBR ASSOCIATION TABLE=20 -------------------------------- -----------------------------=20 =20 B FE3 C E FE4 D=20 C FE2 D D FE1 C=20 =20 =20 =20 FE3 NBR ASSOCIATION TABLE FE4 NBR ASSOCIATION TABLE=20 -------------------------------- -----------------------------=20 =20 B FE4 E D FE2 E=20 C FE1 B E FE3 B=20 =20 Fig. 3(c) Multiple FEs connected in a ring=20 =20 =20 4. Security Considerations=20 =20 Like all protocols, this protocol will have security issues as well.=20 These issues will be researched in detail in future draft versions.=20 =20 =20 5. References=20 =20 5.1. Normative=20 =20 [RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal,=20 "Forwarding and Control Element Separation (ForCES)=20 Framework", RFC 3746, April 2004.=20 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for=20 Separation of IP Control and Forwarding", RFC 3654, =20 November 2003.=20 [ForCESP] F P Team, "ForCES protocol specification",=20 draft-ietf-forces-protocol-00.txt, Sept 2004.=20 =20 5.2. Informative=20 =20 [OSPF] J. Moy, =93OSPF Version 2=94, 1998, RFC 2328.=20 [BGP] Y. Rekhter, T. Li, =93A Border Gateway Protocol 4 (BGP-4)=94= ,=20 1995, RFC 1771.=20 [IS-IS] R. Collela et al., =93Guidelines for OSI NSAP Allocation in= =20 the Internet=94, 1994, RFC 1629.=20 =20 =20 6. Authors' Addresses=20 =20 Furquan Ansari=20 Ansari et al. Expires: Jan 2005 [Page 14] =0C Internet Draft ForCES Discovery July 2004=20 Bell Labs Research, Lucent Tech.=20 101 Crawfords Corner Road=20 Holmdel, NJ 07733=20 USA=20 Phone: +1 732-949-5249=20 Email: furquan@lucent.com=20 =20 =20 Hormuzd Khosravi=20 Intel=20 2111 N.E. 25th Avenue JF3-206=20 Hillsboro, OR 97124-5961=20 USA=20 Phone: +1 503 264 0334=20 Email: hormuzd.m.khosravi@intel.com=20 =20 =20 Jamal Hadi Salim=20 ZNYX Networks=20 Ottawa, Ontario, Canada=20 Email: hadi@znyx.com=20 =20 =20 Joel M. Halpern=20 Megisto systems, Inc.=20 20251 Century Blvd.=20 Germantown, MD, 20874-1162, USA=20 Phone: +1 301 444 17=20 Email: jhalpern@megisto.com=20 =20 =20 7. IANA Considerations=20 There are no IANA considerations at this point since the protocol compl= etely=20 operates within an NE.=20 =20 =20 8. Full Copyright Notice=20 =20 "Copyright (C) The Internet Society (year). This document is subject=20 to the rights, licenses and restrictions contained in BCP 78, and=20 except as set forth therein, the authors retain all their rights."=20 =20 "This document and the information contained herein are provided on=20 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE=20 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE=20 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR=20 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=20 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=20 Ansari et al. Expires: Jan 2005 [Page 15] =0C Internet Draft ForCES Discovery July 2004=20 =20 =20 9. Acknowledgements =20 We would like to thank Thyaga Nandagopal of Lucent Technologies for=20 his thoughts and contributions to the initial draft.=20 =20 Funding for the RFC Editor function is currently provided by the =20 Internet Society.=20 =20 Ansari et al. Expires: Jan 2005 [Page 16] =0C --------------090208080403050105040405-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 16 21:23:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERJiN-0000sL-UU for forces-archive@megatron.ietf.org; Sun, 16 Oct 2005 21:23:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06588 for ; Sun, 16 Oct 2005 21:22:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERJtY-0003YT-FD for forces-archive@IETF.ORG; Sun, 16 Oct 2005 21:34:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.01112FAD@cherry.ease.lsoft.com>; 16 Oct 2005 21:22:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88176201 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 16 Oct 2005 21:22:53 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 16 Oct 2005 21:22:53 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9H1Mohb013580; Mon, 17 Oct 2005 01:22:50 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9H1Mkq8024931; Mon, 17 Oct 2005 01:22:50 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101618224904575 ; Sun, 16 Oct 2005 18:22:49 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 18:22:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Section 6.2.2, protocol scenarios etc. Thread-Index: AcXSkag1UuWRME1qR4ucfjVpvMdILAAJwZQg X-OriginalArrivalTime: 17 Oct 2005 01:22:50.0358 (UTC) FILETIME=[4A14B160:01C5D2B9] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E070D68D0@orsmsx408> Date: Sun, 16 Oct 2005 18:22:33 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Section 6.2.2, protocol scenarios etc. Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Jamal, Pls see my comments below... -----Original Message----- Section 6.2.2 is out of sync with both reality and the Model. The model itself has still incomplete in regards to the neighbor info IMO; there are smaller resolvable issues like missing events etc. This is gonna hold any attempts to go last call if not resolved. [HK] Could you elaborate, or propose updated text and then we can review? There are also issues which held me back in working on the protocol scenarios section. I dont remember the discussions earlier, but did we agree to explicitly turn on/off FEStatus to activate/deactivate the FE? [HK] Yes, as far as I remember. This is still supported in the FE object, so there should be no issue here. There is impedance mismatch between FEObject in protocol and model as well as in the protocol scenarios. We need to resolve this.=20 [HK] I did not see FE object in protocol scenarios. Anyway that section needs to be updated if its out of sync. Hope this helps, Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 16 21:58:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERKH5-00022A-Nj for forces-archive@megatron.ietf.org; Sun, 16 Oct 2005 21:58:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07649 for ; Sun, 16 Oct 2005 21:58:44 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERKSK-0004EV-LA for forces-archive@IETF.ORG; Sun, 16 Oct 2005 22:10:29 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.01113096@cherry.ease.lsoft.com>; 16 Oct 2005 21:58:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88178392 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 16 Oct 2005 21:58:49 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 16 Oct 2005 21:58:48 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9H1wlga030941; Mon, 17 Oct 2005 01:58:47 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9H1wlq8007826; Mon, 17 Oct 2005 01:58:47 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101618584726790 ; Sun, 16 Oct 2005 18:58:47 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 18:58:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] updated text on HA section Thread-Index: AcXQvWeTOb1spO5xSbmrXMJaZpVeUQAJWX+gAHayJSA= X-OriginalArrivalTime: 17 Oct 2005 01:58:47.0564 (UTC) FILETIME=[4FE034C0:01C5D2BE] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E070D68E9@orsmsx408> Date: Sun, 16 Oct 2005 18:58:46 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: updated text on HA section Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Here is the updated figure for HA section. regards Hormuzd FE CE Primary CE Secondary | | | | Asso Estb,Caps exchg | | 1 |<--------------------->| | | | | | All msgs | | 2 |<--------------------->| | | | | | | | | FAILURE | | | | Asso Estb,Caps exchange | 3 |<------------------------------------------>| | | | Event Report (pri CE down) | 4 |------------------------------------------->| | | | All Msgs | 5 |------------------------------------------->| Figure 33: CE Failover for Report Primary Mode From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 09:23:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUxO-0005zb-HG for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 09:23:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11800 for ; Mon, 17 Oct 2005 09:23:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERV8f-0005pe-6t for forces-archive@IETF.ORG; Mon, 17 Oct 2005 09:34:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.01114112@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 9:23:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88236792 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 09:23:07 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 09:23:07 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9HDLRXK062861; Mon, 17 Oct 2005 06:21:27 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E070D68D0@orsmsx408> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129555372.6445.121.camel@localhost.localdomain> Date: Mon, 17 Oct 2005 09:22:52 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Section 6.2.2, protocol scenarios etc. Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E070D68D0@orsmsx408> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit On Sun, 2005-16-10 at 18:22 -0700, Khosravi, Hormuzd M wrote: > Jamal, > > Pls see my comments below... > > -----Original Message----- > > Section 6.2.2 is out of sync with both reality and the Model. > The model itself has still incomplete in regards to the neighbor info > IMO; there are smaller resolvable issues like missing events etc. This > is gonna hold any attempts to go last call if not resolved. > [HK] Could you elaborate, or propose updated text and then we can > review? > The only thing i can propose that can be done in the short while is to remove a lot of the text from 6.2.2 and make it refer to the model draft. Unfortunately the problem with having disjoint things which are incomplete (FEObject being in Model draft). Joel, can you look at that section and cross reference the model and perhaps even suggest what text should stay in 6.2.2? > There are also issues which held me back in working on the protocol > scenarios section. I dont remember the discussions earlier, but did we > agree to explicitly turn on/off FEStatus to activate/deactivate the FE? > [HK] Yes, as far as I remember. This is still supported in the FE > object, so there should be no issue here. > We need more clarity than that. There are too many variables. So what did we agree are the states an FE can be in? I can only think of admin down/up and perhaps a reason why we are in any of the two states example {"admin operation", "just booted", "CE failure" } etc. We need to be that clear. Joel can you also comment on this? > There is impedance mismatch between FEObject in protocol and model as > well as in the protocol scenarios. We need to resolve this. > [HK] I did not see FE object in protocol scenarios. Anyway that section > needs to be updated if its out of sync. > The "things that get configured" when you modify the status of the FE sit in the FE object. Folks, I need closure on this. So please comment. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 10:32:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERW28-00069s-Nw for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 10:32:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15656 for ; Mon, 17 Oct 2005 10:32:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWDU-0007t2-3w for forces-archive@IETF.ORG; Mon, 17 Oct 2005 10:43:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.011143FF@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 10:32:11 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88240966 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 10:32:09 -0400 Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 10:31:02 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j9HEV2rU122292 for ; Mon, 17 Oct 2005 14:31:02 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9HEV1pY235320 for ; Mon, 17 Oct 2005 15:31:01 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j9HEV1iI009162 for ; Mon, 17 Oct 2005 15:31:01 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j9HEV1Fp009151; Mon, 17 Oct 2005 15:31:01 +0100 Received: from [127.0.0.1] (dhcp71-149.zurich.ibm.com [9.4.71.149]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA66368; Mon, 17 Oct 2005 16:31:01 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E070969CC@orsmsx408> <1129310375.6407.106.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.uk.ibm.com id j9HEV2rU122292 Approved-By: Robert Haas Message-ID: <4353B5AC.3000102@zurich.ibm.com> Date: Mon, 17 Oct 2005 16:31:08 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: updated text on HA section Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1129310375.6407.106.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Jamal, Looks fine to me too. Regards, -Robert Jamal Hadi Salim wrote: >On Fri, 2005-14-10 at 10:15 -0700, Khosravi, Hormuzd M wrote: > =20 > >>Jamal, >> >>Pls read the last para, it has the text on multicast IDs. >>If you would like to add something more that I missed, feel free. >> >> =20 >> > >Ok, my bad. It looks good - but lets hear from Robert and i will make >this the last thing i update.=20 > >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 10:42:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWBa-0008U7-LA for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 10:42:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16145 for ; Mon, 17 Oct 2005 10:41:51 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWMw-0008AC-0s for forces-archive@IETF.ORG; Mon, 17 Oct 2005 10:53:42 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.01114438@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 10:41:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88241763 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 10:41:55 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 10:41:55 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9HEeQXK063317 for ; Mon, 17 Oct 2005 07:40:26 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-YOZzvZqphp5wQE+EAdja" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129560112.6376.3.camel@localhost.localdomain> Date: Mon, 17 Oct 2005 10:41:52 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: updated FEPO text and xml in appendix To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 --=-YOZzvZqphp5wQE+EAdja Content-Type: text/plain Content-Transfer-Encoding: 7bit the usual include <"please comment"> I have updated the xml as well in the appendix and synchronized the two items. For clarity both are in the attached text file. I may have removed one or two things or added one or two things. I do that with code sometimes too - just to see if people are paying attention during code reviews . cheers, jamal --=-YOZzvZqphp5wQE+EAdja Content-Disposition: attachment; filename=FEPOxml.txt Content-Type: text/plain; name=FEPOxml.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 6.2.1. FE Protocol LFB The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The FE Protocol LFB Class ID is assigned the value 0x1. The FE Protocol LFB Instance ID is assigned the value 0x1. There MAY be one and only one instance of the FE Protocol LFB in an FE. The values of the attributes in the FE Protocol LFB have pre-defined default values that are specified here. Unless explicit changes are made to these values using Config messages from the CE, these default values MUST be used for the operation of the protocol. The formal definition of the FE Protocol LFB can be found in Appendix C The FE Protocol LFB consists of the following elements: o FE Protocol capabilities (read-only): * Supported ForCES protocol version(s) by the FE * Any TML capability description(s) o FE Protocol attributes (can be read and set): * Current version of the ForCES protocol * FE unicast ID * FE multicast ID(s) list - this is a list of multicast IDs that the FE belongs to. These IDs are configured by the CE. * CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat Dead Interval (CE HDI)' as described below defines the operating parameters for the FE to check the CE liveness. The policy values with meanings are listed as below: 0(default) - This policy specifies that CE will send a Heartbeat Message to FE whenever CE reaches a time interval within which no other PL messages were sent from CE to FE; refer to Section 3.3.2 for details. The CE HDI attribute as Doria (Ed.), et al. Expires February 2, 2006 [Page 42] Internet-Draft ForCES August 2005 described below is tied to this policy. If the FE has not received any PL messages within CE HDI period it declares the connectivity lost. The CE independently chooses the time interval to send the Heartbeat messages to FE - care must be exercised to ensure the CE->FE HB interval is smaller than the CE HDI assigned. 1 - The CE will not generate any HB messages. This actually means CE does not want the FE to check the CE liveness. Others - reserved. * CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses to check the CE liveness. If FE has not received any messages from CE within this time interval, FE deduces lost connectivity which implies that the CE is dead or the association to the CE is lost. Default value 30 s. * FE heartbeat policy - This policy, along with the parameter 'FE Heartbeat Interval (FE HI)', define the operating parameters for how the FE should behave so that the CE can deduce its liveliness. The policy values and the meanings are: 0(default) - The FE should not generate any Heartbeat messages. In this scenario, the CE is responsible for checking FE liveness by setting the PL header ACK flag of the message it sends to AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat Request Message. Refer to Section 6.9 and Section 3.3.2 for details. 1 - This policy specifies that FE must actively send a Heartbeat Message if it reaches the time interval assigned by the FE HI as long as no other messages were sent from FE to CE during that interval as described in Section 3.3.2. Others - Reserved. * FE Heartbeat Interval (FE HI) - The time interval the FE should use to send HB as long as no other messages were sent from FE to CE during that interval as described in Section 3.3.2. The deafult value for a FE HI is 500ms. * Primary CEID - The CEID that the FE is associated with. * Backup CEs - The list of backup CEs an FE is associated with. Refer to Section 8 for details. Doria (Ed.), et al. Expires February 2, 2006 [Page 43] Internet-Draft ForCES August 2005 * FE restart policy - This specifies the behavior of the FE during a FE restart. The restart may be from a FE failure or other reasons that have made FE down and then need to restart. The values are defined as below: 0(default)- just restart the FE from scratch. In this case, the FE should start from pre-association phase definitely. 1 - restart the FE from an intermediate state. In this case, the FE itself decides from which state it restarts. For example, if the FE still keeps enough infomation of pre- association phase after some failure, it then has the right just to start from post-associatin phase with this policy case. Others - Reserved * CE failover policy - This specifies the behavior of the FE during a CE failure and restart time interval, or when the FE loses the CE association. It should be noted that this policy in the case of HA only takes effect after total failure to connect to a new CE. A timeout parameter, the CE Timeout Interval (CE TI) is associated with this attribute. Values of this policy are defined as below: 0(default) - The FE should continue running and do what it can even without an associated CE. This basically makes the FE support CE Graceful restart. Note that if the CE still has not been restarted or hasn't been associated back to the FE, after the CE TI has expired, the FE will go operationally down. 1 - FE should go down to stop functioning immediately. 2 - FE should go inactive to temporarily stop functioning. If the CE still has not been restarted after a time interval of specified by the CE TI, the FE will go down completely. Others - Reserved * CE Timeout Interval (CE TI) - The time interval associated with the CE failover policy case '0' and '2'. The default value is set to 300 seconds. Note that it is advisable to set the CE TI value much higher than the CE Heartbeat Dead Interval (CE HDI) since the effect of expiring this parameter is devastating to the operation of the FE. ... ... ... ... ... ... ... Doria (Ed.), et al. Expires February 2, 2006 [Page 44] Internet-Draft ForCES August 2005 Appendix C. Forces Protocol LFB schema The schema described below conforms to the LFB schema (language?) described in Forces Model draft[FE-MODEL] FEORange1 The FEO HB policy type uchar FEORange2 The FEO Other policy type uchar FEPO 1 The FE Protocol Object 1.0 baseclass SupportableVersions the table of ForCES versions that FE supports Doria (Ed.), et al. Expires February 2, 2006 [Page 82] Internet-Draft ForCES August 2005 u8 CurrentRunningVersion Currently running ForCES version u8 FEID Unicast FEID uint32 MulticastFEIDs the table of all multicast IDs uint32 CEHBPolicy The CE Heartbeat Policy FEORange1 CEHDI The CE Heartbeat Dead Interval in millisecs uint32 FEHBPolicy The FE Heartbeat Policy FEORange1 Doria (Ed.), et al. Expires February 2, 2006 [Page 83] Internet-Draft ForCES August 2005 FEHI The FE Heartbeat Interval in millisecs uint32 CEID The Primary CE this FE is associated with uint32 BackupCEs The table of all backup CEs other than the primary uint32 FERestartPolicy The FE Restart Policy FEORange1 CEFailoverPolicy The CE Failover Policy FEORange2 CETI The CE Timeout Interval in millisecs uint32 Doria (Ed.), et al. Expires February 2, 2006 [Page 84] Internet-Draft ForCES August 2005 C.1. Capabilities At the moment only the SupportableVersions capability is owned by this LFB. Supportable Versions enumerates all ForCES versions that an FE supports. C.2. Attributes All Attributes are explained in Section 6.2.1. --=-YOZzvZqphp5wQE+EAdja-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 10:58:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWRD-00043n-U0 for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 10:58:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17196 for ; Mon, 17 Oct 2005 10:58:00 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWcY-0000Gg-PY for forces-archive@IETF.ORG; Mon, 17 Oct 2005 11:09:52 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0111447B@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 10:58:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88243778 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 10:58:04 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 10:58:04 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9HEuZXK063451 for ; Mon, 17 Oct 2005 07:56:35 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129561081.6376.9.camel@localhost.localdomain> Date: Mon, 17 Oct 2005 10:58:01 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Updated section 7 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit the usual include <"please comment"> applies. Text mostly put in sync with rest of reality. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 10:58:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWRv-00049z-Kc for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 10:58:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17244 for ; Mon, 17 Oct 2005 10:58:44 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWdH-0000IH-6B for forces-archive@IETF.ORG; Mon, 17 Oct 2005 11:10:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.011145DE@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 10:58:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88243823 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 10:58:49 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 10:58:49 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9HEvKXK063470 for ; Mon, 17 Oct 2005 07:57:20 -0700 (PDT) References: <1129561081.6376.9.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-na15aUyuKZiwoUiZ2d1o" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129561126.6376.11.camel@localhost.localdomain> Date: Mon, 17 Oct 2005 10:58:46 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Updated section 7 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1129561081.6376.9.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 --=-na15aUyuKZiwoUiZ2d1o Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-17-10 at 10:58 -0400, Jamal Hadi Salim wrote: > the usual include <"please comment"> applies. > > Text mostly put in sync with rest of reality. Of course you cant comment if i dont attach it ;-> cheers, jamal --=-na15aUyuKZiwoUiZ2d1o Content-Disposition: attachment; filename=sec7.txt Content-Type: text/plain; name=sec7.txt; charset=utf-8 Content-Transfer-Encoding: 7bit 7. Protocol Scenarios 7.1. Association Setup state The associations among CEs and FEs are initiated via Association setup message from the FE. If a setup request is granted by the CE, a successful setup response message is sent to the FE. If CEs and FEs are operating in an insecure environment then the security association have to be established between them before any association messages can be exchanged. The TML will take care of establishing any security associations. This is typically followed by capability query, topology query, etc. When the FE is ready to start forwarding data traffic, it sends a FE UP Event message to the CE. When the CE is ready, it by enabling the FE by setting the FEStatus to Adminup [Refer to Model draft for details]. This indicates to the FE to start forwarding data traffic. At this point the association establishment is complete. These sequences of messages are illustrated in the Figure below. Doria (Ed.), et al. Expires February 2, 2006 [Page 64] Internet-Draft ForCES August 2005 FE PL CE PL | | | Asso Setup Req | |---------------------->| | | | Asso Setup Resp | |<----------------------| | | | LFBx Query capability | |<----------------------| | | | LFBx Query Resp | |---------------------->| | | | FEO Query (Topology) | |<----------------------| | | | FEO Query Resp | |---------------------->| | | | FE UP Event | |---------------------->| | | | Config FEO Adminup | |<----------------------| | | Figure 30: Message exchange between CE and FE to establish an NE association On successful completion of this state, the FE joins the NE. 7.2. Association Established state or Steady State In this state the FE is continously updated or queried. The FE may also send asynchronous event notifications to the CE or synchronous heartbeat messages. This continues until a termination (or deactivation) is initiated by either the CE or FE. Figure below helps illustrate this state. Doria (Ed.), et al. Expires February 2, 2006 [Page 65] Internet-Draft ForCES August 2005 FE PL CE PL | | | Heart Beat | |<---------------------------->| | | | Heart Beat | |----------------------------->| | | | Config-set LFBy (Event sub.) | |<-----------------------------| | | | Config Resp LFBy | |----------------------------->| | | | Config-set LFBx Attr | |<-----------------------------| | | | Config Resp LFBx | |----------------------------->| | | |Config-Query LFBz (Stats) | |<--------------------------- -| | | | Query Resp LFBz | |----------------------------->| | | | FE Event Report | |----------------------------->| | | | Config-Del LFBx Attr | |<-----------------------------| | | | Config Resp LFBx | |----------------------------->| | | | Packet Redirect LFBx | |----------------------------->| | | | Heart Beat | |<-----------------------------| . . . . | | Figure 31: Message exchange between CE and FE during steady-state communication Doria (Ed.), et al. Expires February 2, 2006 [Page 66] Internet-Draft ForCES August 2005 Note that the sequence of messages shown in the figure serve only as examples and the messages exchange sequences could be different from what is shown in the figure. Also, note that the protocol scenarios described in this section do not include all the different message exchanges which would take place during failover. That is described in the HA section 8. Doria (Ed.), et al. Expires February 2, 2006 [Page 67] --=-na15aUyuKZiwoUiZ2d1o-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 11:03:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWWM-0005Ky-60 for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 11:03:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17732 for ; Mon, 17 Oct 2005 11:03:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWhh-0000Vx-T0 for forces-archive@IETF.ORG; Mon, 17 Oct 2005 11:15:10 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0111458F@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 11:03:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88244370 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 11:03:24 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 11:03:23 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9HF1sXK063539 for ; Mon, 17 Oct 2005 08:01:55 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-wkknUWJso7hCuc/vY31b" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129561401.6376.18.camel@localhost.localdomain> Date: Mon, 17 Oct 2005 11:03:21 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: updated section 8 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --=-wkknUWJso7hCuc/vY31b Content-Type: text/plain Content-Transfer-Encoding: 7bit The usual disclaimer applies "please comment". There is nothing controversial since discussion already happened on the list - but no harm in glossing over it. Updated text thanks to Hormuzd. cheers, jamal --=-wkknUWJso7hCuc/vY31b Content-Disposition: attachment; filename=sec8.txt Content-Type: text/plain; name=sec8.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 8.1. Responsibilities for HA TML level - Transport level: 1. The TML controls logical connection availability and failover. 2. The TML also controls peer HA managements. At this level, control of all lower layers, for example transport level (such as IP addresses, MAC addresses etc) and associated links going down are the role of the TML. PL Level: All the other functionality including configuring the HA behavior during setup, the CEIDs are used to identify primary, secondary CEs, protocol Messages used to report CE failure (Event Report), Heartbeat messages used to detect association failure, messages to change primary CE (config - move), and other HA related operations described before are the PL responsibility. To put the two together, if a path to a primary CE is down, the TML would take care of failing over to a backup path, if one is available. If the CE is totally unreachable then the PL would be informed and it will take the appropriate actions described before. Doria (Ed.), et al. Expires February 2, 2006 [Page 70] --=-wkknUWJso7hCuc/vY31b-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 11:10:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWde-0008N0-W9 for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 11:10:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18262 for ; Mon, 17 Oct 2005 11:10:51 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWp0-0000m3-NN for forces-archive@IETF.ORG; Mon, 17 Oct 2005 11:22:43 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.01114665@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 11:10:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88245236 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 11:10:56 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 11:10:56 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9HF9RXK063604 for ; Mon, 17 Oct 2005 08:09:27 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-EeT4COFRIICs/yOCPTo0" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129561853.6376.23.camel@localhost.localdomain> Date: Mon, 17 Oct 2005 11:10:53 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: updated IANA section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 --=-EeT4COFRIICs/yOCPTo0 Content-Type: text/plain Content-Transfer-Encoding: 7bit The usual disclaimer applies ladies and gentlemen - "please comment". This is preliminary text that starts the first capture. Text thanks to Avri. cheers, jamal --=-EeT4COFRIICs/yOCPTo0 Content-Disposition: attachment; filename=iana.txt Content-Type: text/plain; name=iana.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Appendix B. IANA Considerations Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" (RFC 2434 [RFC2434]), the following name spaces are defined in ForCES. o Message Type Name Space (add xref) o Header Flags (add xref) o TLV Type (add xref) o Result TLV value (add xref) o LFB Class ID (add xref) o Result: Association Setup Repsonse (add xref) o Reason: Association Teardown Message (add xref) o Operation type (add xref) o Configuration Request: Operation Result (add xref) B.1. Message Type Name Space The Message Type is an 8 bit value. The following is the guideline for defining the Message Type namespace Message Types 0x00 - 0x0F Message Types in this range are part of the base ForCES Protocol. Message Types in this range are allocated through an IETF consensus action. [RFC2434] Values assigned by this specification: 0x00 ............... Heartbeat 0x01 ............... Association Messages 0x02 ............... Configuration Messages 0x03 ............... Query Messages 0x04 ............... Event Notifications 0x05 ............... Packet Redirection Message Types 0x10 - 0x7F Message Types in this range are Specification Required [RFC2434] Message Types using this range must be documented in an RFC or other permanent and readily available references. Doria (Ed.), et al. Expires February 2, 2006 [Page 78] Internet-Draft ForCES August 2005 Message Types 0x80 - 0xFF Message Types in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Message Type Name Space is unnecessary. B.2. Operation Type The Operation Type name space is 16 bits long. The following is the guideline for managing the Operation Type Name Space. Operation Type 0x0000-0x00FF Operation Types in this range are allocated through an IETF consensus process. [RFC2434]. Values assigned by this specification: 0x0000 Reserved 0x0001 ADD Operation Type 0x0100-0x7FFF Operation Types using this range must be documented in an RFC or other permanent and readily available references. [RFC2434]. Operation Type 0x8000-0xFFFF Operation Types in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Operation Type Name Space is unnecessary. B.3. Header Flags The Header flag field is 32 bits long Header flags are part of the ForCES base protocol. Header flags are allocated through an IETF consensus action [RFC2434]. TLV Result Values in this range are allocated through an IETF consensus process. [RFC2434]. Values assigned by this specification: B.4. LFB Class Id Name Space TheLFB Class ID name space is 32 bits long. The following iws the guideline for managing the TLV Result Name Space. LFB Class ID 0x00000000-0x0000FFFF LFB Class IDs in this range are allocated through an IETF consensus process. [RFC2434]. Values assigned by this specification: Doria (Ed.), et al. Expires February 2, 2006 [Page 79] Internet-Draft ForCES August 2005 0x00000000 Reserved 0x00000001 FE Protocol LFB 0x00000002 FE LFB LFB Class ID 0x00010000-0x7FFFFFFF LFB Class IDs in this range are Specification Required [RFC2434] LFB Class ID using this range must be documented in an RFC or other permanent and readily available references. [RFC2434]. LFB Class Id 0x80000000-0xFFFFFFFFF LFB Class IDs in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the LFB Class ID Space is unnecessary. B.5. Association Setup Repsonse The Association Setup Repsonse name space is 16 bits long. The following is the guideline for managing the Association Setup Repsonse Name Space. Association Setup Repsonse 0x0000-0x00FF Association Setup Repsonses in this range are allocated through an IETF consensus process. [RFC2434]. Values assigned by this specification: 0x0000 Succcess 0x0001 FE ID Invalid 0x0002 Too many associations 0x0003 Permission Denied Association Setup Repsonse 0x0100-0x0FFF Association Setup Repsonses in this range are Specification Required [RFC2434] Values using this range must be documented in an RFC or other permanent and readily available references. [RFC2434]. Association Setup Repsonse 0x80000000-0xFFFFFFFFF Association Setup Repsonses in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Association Setup Repsonses Name Space is unnecessary. B.6. Association Teardown Message The Association Teardown Message name space is 32 bits long. The following is the guideline for managing the TLV Result Name Space. Doria (Ed.), et al. Expires February 2, 2006 [Page 80] Internet-Draft ForCES August 2005 Association Teardown Message 0x00000000-0x0000FFFF Association Teardown Messages in this range are allocated through an IETF consensus process. [RFC2434]. Values assigned by this specification: 0x00000000 Normal - Teardown by Administrator 0x00000001 Error - Out of Memory 0x00000002 Error - Application Crash 0x000000FF Error - Unspecified Association Teardown Message 0x00010000-0x7FFFFFFF Association Teardown Messages in this range are Specification Required [RFC2434] Association Teardown Messages using this range must be documented in an RFC or other permanent and readily available references. [RFC2434]. LFB Class Id 0x80000000-0xFFFFFFFFF Association Teardown Messages in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Association Teardown Message Name Space is unnecessary. B.7. Configuration Request Result The Configuration Request name space is 32 bits long. The following is the guideline for managing the Configuration Request Name Space. Configuration Request 0x0000-0x00FF Configuration Requests in this range are allocated through an IETF consensus process. [RFC2434]. Values assigned by this specification: 0x0000 Success 0x0001 FE ID Invalid 0x0003 Permission Denied Configuration Request 0x0100-0x7FFF Configuration Requests in this range are Specification Required [RFC2434] Configuration Requests using this range must be documented in an RFC or other permanent and readily available references. [RFC2434]. 0x8000-0xFFFF Configuration Requests in this range are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Configuration Request Name Space is unnecessary. Doria (Ed.), et al. Expires February 2, 2006 [Page 81] --=-EeT4COFRIICs/yOCPTo0-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 11:49:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERXEW-0008J7-ES for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 11:49:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20359 for ; Mon, 17 Oct 2005 11:48:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERXPr-0001sE-IY for forces-archive@IETF.ORG; Mon, 17 Oct 2005 12:00:49 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0111470E@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 11:49:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88250296 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 11:49:01 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 11:49:00 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9HFlVXK063914 for ; Mon, 17 Oct 2005 08:47:31 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-lqG4W4lmeNTK2/ubB9il" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129564138.6376.24.camel@localhost.localdomain> Date: Mon, 17 Oct 2005 11:48:58 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: updated section 9 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc --=-lqG4W4lmeNTK2/ubB9il Content-Type: text/plain Content-Transfer-Encoding: 7bit you know what to do ... cheers, jamal --=-lqG4W4lmeNTK2/ubB9il Content-Disposition: attachment; filename=sec9.txt Content-Type: text/plain; name=sec9.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 9. Security Considerations ForCES architecture identifies several levels of security in [FE- ARCH]. ForCES PL uses security services provided by the ForCES TML layer. TML layer provides security services such as endpoint authentication service, message authentication service and confidentiality service. Endpoint authentication service is invoked at the time of pre-association connection establishment phase and message authentication is performed whenever FE or CE receives a packet from its peer. Following are the general security mechanism that needs to be in place for ForCES PL layer. o Security mechanism are session controlled that is once the security is turned ON depending upon the chosen security level (No Security, Authentication only, Confidentiality), it will be in effect for the entire duration of the session. o Operator should configure the same security policies for both primary and backup FE's and CE's (if available). This will ensure uniform operations, and to avoid unnecessary complexity in policy configuration. o ForCES PL endpoints SHOULD pre-established connections with both primary and backup CE's. This will reduce the security messages and enable rapid switchover operations for HA. 9.1. No Security When No security is chosen for ForCES protocol communication, both endpoint authentication and message authentication service needs be performed by ForCES PL layer. Both these mechanism are weak and does not involve cryptographic operation. Operator can choose "No security" level when the ForCES protocol endpoints are within an single box. In order to have interoperable and uniform implementation across various security levels, each CE and FE endpoint MUST implement this level. The operations that are being performed for "No security" level is required even if lower TML security services are being used. 9.1.1. Endpoint Authentication Each CE and FE PL layer maintain set of associations list as part of configuration. This is done via CEM and FEM interfaces. FE MUST connect to only those CE's that are configured via FEM similarly CE should accept the connection and establish associations for the FE's Doria (Ed.), et al. Expires February 2, 2006 [Page 71] Internet-Draft ForCES August 2005 which are configured via CEM. CE should validate the FE identifier before accepting the connection during the pre-association phase. 9.1.2. Message authentication When CE or FE generates initiates a message, the receiving endpoint MUST validate the initiator of the message by checking the common header CE or FE identifiers. This will ensure proper protocol functioning. We recommend this extra step processing even if the underlying TLM layer security services. 9.2. ForCES PL and TML security service This section is applicable if operator wishes to use the TML security services. ForCES TML layer MUST support one or more security service such as endpoint authentication service, message authentication service, confidentiality service as part of TML security layer functions. It is the responsibility of the operator to select appropriate security service and configure security policies accordingly. The details of such configuration is outside the scope of ForCES PL and is depending upon the type of transport protocol, nature of connection. All these configurations should be done prior to starting the CE and FE. When certificates-based authentication is being used at TML layer, the certificate can use ForCES specific naming structure as certificate names and accordingly the security policies can be configured at CE and FE. 9.2.1. Endpoint authentication service When TML security services are enabled. ForCES TML layer performs endpoint authentication. Security association is established between CE and FE and is transparent to the ForCES PL layer. We recommend that FE after establishing the connection with the primary CE, should establish the security association with the backup CE (if available). During the switchover operation CE's security state associated with each SA's are not transferred. SA between primary CE and FE and backup CE and FE are treated as two separate SA's. 9.2.2. Message authentication service This is TML specific operation and is transparent to ForCES PL layer. For details refer to Section 4. Doria (Ed.), et al. Expires February 2, 2006 [Page 72] Internet-Draft ForCES August 2005 9.2.3. Confidentiality service This is TML specific operation and is transparent to ForCES PL layer. For details refer to Section 4. Doria (Ed.), et al. Expires February 2, 2006 [Page 73] --=-lqG4W4lmeNTK2/ubB9il-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 12:09:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERXYg-00033H-E4 for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 12:09:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21560 for ; Mon, 17 Oct 2005 12:09:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERXk1-0002Wl-Sj for forces-archive@IETF.ORG; Mon, 17 Oct 2005 12:21:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.01114880@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 12:09:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88252551 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 12:09:51 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 12:09:51 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9HG8LXK064103 for ; Mon, 17 Oct 2005 09:08:22 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129565384.6376.30.camel@localhost.localdomain> Date: Mon, 17 Oct 2005 12:09:44 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Appendix F To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Should we keep appendix F around? Weiming does this fit as something that goes in the draft we planned to publish? If yes, I recommend its removal from this draft. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 18:02:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERd4J-0002Io-Qi for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 18:02:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09668 for ; Mon, 17 Oct 2005 18:02:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERdFc-0005U4-13 for forces-archive@IETF.ORG; Mon, 17 Oct 2005 18:14:43 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.01114E9E@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 18:02:06 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88277435 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 18:02:05 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 18:02:03 -0400 Received: from [219.82.187.152] by 202.96.99.56 with StormMail ESMTP id 54342.2105028806; Tue, 18 Oct 2005 06:43:23 +0800 (CST) References: <1129565384.6376.30.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <004901c5d366$72988410$1f12fea9@wwm1> Date: Tue, 18 Oct 2005 06:02:19 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Appendix F Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Jamal, I'l review and comments all your other posted text this night (now it's morning), I have to be out now. Thanks for your efforts. Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > Should we keep appendix F around? > Weiming does this fit as something that goes in the draft we planned to > publish? If yes, I recommend its removal from this draft. Sure, I think it is also not very complete to mention TML implementation here, therefore, it is better to remove it. > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 17 23:14:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERhvv-00057a-LD for forces-archive@megatron.ietf.org; Mon, 17 Oct 2005 23:14:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28005 for ; Mon, 17 Oct 2005 23:14:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERi7K-0005uB-U7 for forces-archive@IETF.ORG; Mon, 17 Oct 2005 23:26:26 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.01115476@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 23:14:31 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88295056 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 23:14:29 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 23:14:29 -0400 Received: from [71.254.23.91] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12667246; Mon, 17 Oct 2005 21:13:51 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E070D68D0@orsmsx408> <1129555372.6445.121.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051017231025.03003d70@localhost> Date: Mon, 17 Oct 2005 23:14:24 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Section 6.2.2, protocol scenarios etc. Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1129555372.6445.121.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 At 09:22 AM 10/17/2005, Jamal Hadi Salim wrote: >Joel, can you look at that section and cross reference the model and >perhaps even suggest what text should stay in 6.2.2? Suggested text: 6.2.2 FE Object LFB The FE Object LFB Class is defined in the [MODEL] document. It captures the high level properties of the FE that the CE needs to know to begin working with the FE. The class ID for this LFB Class is assigned in [Model]. The signular instance of this class will always exist, and will always have instance ID 1 within its class. It is common, although not mandatory, for a CE to fetch much of the attribute and capability information from this LFB instance when the CE begins controlling the operation of the FE. Yours, Joel PS: I am not suggesting a section reference, because those may still change. It's hard enough getting those right within a document (xml2rfc does it nicely.) From owner-forces@PEACH.EASE.LSOFT.COM Tue Oct 18 03:49:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmEJ-0004bf-GW for forces-archive@megatron.ietf.org; Tue, 18 Oct 2005 03:49:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10814 for ; Tue, 18 Oct 2005 03:49:44 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERmPn-00047R-78 for forces-archive@IETF.ORG; Tue, 18 Oct 2005 04:01:44 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0111579B@cherry.ease.lsoft.com>; Tue, 18 Oct 2005 3:49:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88306970 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Oct 2005 03:49:48 -0400 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 18 Oct 2005 03:49:47 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOJ00HFWQ5GUK@szxga02-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Oct 2005 15:58:28 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOJ00EVPQ5GSC@szxga02-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Oct 2005 15:58:28 +0800 (CST) Received: from lenovo111 ([10.110.100.34]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOJ00FF5Q5ABC@szxml02-in.huawei.com>; Tue, 18 Oct 2005 15:58:22 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <468F3FDA28AA87429AD807992E22D07E070D68D0@orsmsx408> <1129555372.6445.121.camel@localhost.localdomain> <6.2.1.2.0.20051017231025.03003d70@localhost> Approved-By: Xiaoyi Guo Message-ID: <001601c5d3b8$a5dec350$22646e0a@china.huawei.com> Date: Tue, 18 Oct 2005 15:50:45 +0800 Reply-To: Xiaoyi Guo Sender: Forwarding and Control Element Separation From: Xiaoyi Guo Organization: Huawei Tech. Subject: Re: Section 6.2.2, protocol scenarios etc. Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7BIT hi, Joel ----- Original Message ----- From: "Joel M. Halpern" To: Sent: Tuesday, October 18, 2005 11:14 AM Subject: Re: Section 6.2.2, protocol scenarios etc. > At 09:22 AM 10/17/2005, Jamal Hadi Salim wrote: >>Joel, can you look at that section and cross reference the model and >>perhaps even suggest what text should stay in 6.2.2? > > Suggested text: > 6.2.2 FE Object LFB > The FE Object LFB Class is defined in the [MODEL] document. It captures > the high level properties of the FE that the CE needs to know to begin > working with the FE. The class ID for this LFB Class is assigned in > [Model]. The signular instance of this class will always exist, and will I think you want to say the singular instance ? > always have instance ID 1 within its class. It is common, although not > mandatory, for a CE to fetch much of the attribute and capability > information from this LFB instance when the CE begins controlling the > operation of the FE. > > Yours, > Joel > From BrendaLevy@eesus.jnj.com Tue Oct 18 07:31:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERphF-00038v-I9; Tue, 18 Oct 2005 07:31:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22946; Tue, 18 Oct 2005 07:31:48 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERpsl-0001w9-EU; Tue, 18 Oct 2005 07:43:52 -0400 Received: from ppp85-140-51-64.pppoe.mtu-net.ru ([85.140.51.64]) by mx2.foretec.com with smtp (Exim 4.24) id 1ERpgz-0007yx-9G; Tue, 18 Oct 2005 07:31:42 -0400 Received: from mRu@localhost by hgo.int (8.11.6/8.11.6); Tue, 18 Oct 2005 11:33:31 -0500 Message-ID: From: "Jennifer Rivera" Reply-To: "Jennifer Rivera" To: forces-archive@ietf.org, forces-protocol-admin@ietf.org, forces-protocol@ietf.org, forest.horner@ietf.org, forest.north@ietf.org Subject: Re: OEM Photoshop, Symantec, & AutoCAD on Sale Now Date: Tue, 18 Oct 2005 14:29:31 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: BrendaLevy@eesus.jnj.com Content-Type: multipart/mixed; boundary="--fphqdJ0aeMAl20L2M8l" X-Spam-Score: 3.2 (+++) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Saf ----fphqdJ0aeMAl20L2M8l Content-Type: text/html; Content-Transfer-Encoding: quoted-printable N
Opt-in Email Special Offer &n= bsp;   unsubscribe me
Microsoft Office P= rofessional Edition *2003*
Microsoft
=
SEARCH

=

TOP 10 NEW TITLES

= = = <= td width=3D4> <= td width=3D4> 

 = ON SALE NOW!

 1 Office Pro Edition 2003
 2= Windows XP Pro
 3 = Adobe Creative Suite Premium
 4 Systemworks Pro 2004 Edition
 5 = Flash MX 2004
 6 <= a href=3Dhttp://outlsoftware.com/?K>Corel Painter 8
 7 Adobe Acrobat 6.0
 8= Windows 2003 Server
 9 Alias Maya 6.0 Wavefront
 10 Adobe Premiere
  See more by this manufact= urer
   Microsoft
  Apple Software
  Customers also bought
  these other items...



Choose:=
 
List Price:$899.00
Price:$69.99
You Save:$830.0= 1 (92%)

=

Availabil= ity: Available for INSTANT download!
Coupon Code: ISe229 Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

F= eatures:

  • Analyze and manage business information using Access databases <= /font>
  • Exchange data with other syst= ems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-m= ail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date Coupon= Expires: May 30th, 2005
Average Cust= omer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Windows XP= Professional or Longhorn Edition
Microsoft
Choose:
 

<= b>Price:
L= ist Price:$279.00
$49.99
You Save:<= /td>$229.01 (85%)



Availability: Available for INSTANT download!
= Coupon Code: ISe229
Media: CD-ROM / Download
System requirem= ents  |  Accessories  |  Other Versions

Features:

  • Designed for businesses of all size= s
  • Manage digital pictures, m= usic, video, DVDs, and more
  • = More security with the ability to encrypt files and folders
    • <= li class=3Dsmall>Built-in voice, video, and instant messagi= ng support
  • Integration with = Windows servers and management solutions

Sales Rank: #2
Shipping: International= /US or via instant download
Date Coupon Expires: May 30th, 2005=
Average Customer Review: 3D"5 Ba= sed on 868 reviews. Write a review.

Adobe Creative Suite Premium
Adobe
Choose:
 

List Price: $1149.00
Price:$99.99
You Save:= $849.01 (90%)



Avail= ability: Available for INSTANT download!
Coupon Code: ISe22= 9
Media: CD-ROM / Download

= System requirements  | = Accessories  |  Other Versions

Features:

  • An integrated design environment featuring the industry&= #39;s foremost design tools
  • = In-depth tips, expert tricks, and comprehensive design resources
  • Intuitive file finding, smooth workfl= ow, and common interface and toolset
  • Single installer--control what you install and when you install i= t
  • Cross-media publishing--cr= eate content for both print and the Web

Sales Rank: #3
Shipping: Intern= ational/US or via instant download
Date Coupon Expires: May 30t= h, 2005
Average Customer Review: Based on 498 reviews. Write a revi= ew.

----fphqdJ0aeMAl20L2M8l-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Oct 18 16:57:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERyWB-00058u-B4 for forces-archive@megatron.ietf.org; Tue, 18 Oct 2005 16:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20471 for ; Tue, 18 Oct 2005 16:56:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERyhl-0001bD-R8 for forces-archive@IETF.ORG; Tue, 18 Oct 2005 17:09:07 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.01116175@cherry.ease.lsoft.com>; Tue, 18 Oct 2005 16:57:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88372454 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Oct 2005 16:57:00 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 18 Oct 2005 16:57:00 -0400 Received: from [71.254.23.91] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12670220 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Oct 2005 14:56:20 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051018165624.02cb4960@localhost> Date: Tue, 18 Oct 2005 16:56:57 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Fwd: I-D ACTION:draft-halpern-forces-lfblibrary-base-00.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Here is the draft announcement for the library draft. Yours, Joel >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : A base Library for use with the ForCES Protocol > and Model > Author(s) : J. Halpern > Filename : draft-halpern-forces-lfblibrary-base-00.txt > Pages : 23 > Date : 2005-10-18 > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-halpern-forces-lfblibrary-base-00.txt From owner-forces@PEACH.EASE.LSOFT.COM Tue Oct 18 18:31:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzzQ-0000h8-KZ for forces-archive@megatron.ietf.org; Tue, 18 Oct 2005 18:31:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03956 for ; Tue, 18 Oct 2005 18:31:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES0B2-0006aP-Jo for forces-archive@IETF.ORG; Tue, 18 Oct 2005 18:43:24 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.011163F4@cherry.ease.lsoft.com>; Tue, 18 Oct 2005 18:31:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88378125 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Oct 2005 18:30:59 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 18 Oct 2005 18:30:59 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9IMUtTq024669; Tue, 18 Oct 2005 22:30:55 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9IMUeO8028422; Tue, 18 Oct 2005 22:30:55 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005101815305505472 ; Tue, 18 Oct 2005 15:30:55 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Oct 2005 15:30:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: Call for Agenda Items, ForCES Meeting at IETF 64 thread-index: AcXNrniqEI+3Fok0QnqHKKO9qyvRzAGhQGbA X-OriginalArrivalTime: 18 Oct 2005 22:30:55.0218 (UTC) FILETIME=[9A9ABD20:01C5D433] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 18 Oct 2005 15:30:54 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Call for Agenda Items, ForCES Meeting at IETF 64 Comments: cc: Patrick Droz To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable All, The draft agenda for the ForCES meeting at IETF 64 can be found at the following address: http://www3.ietf.org/proceedings/05nov/agenda/forces.txt=20 Please email me and Patrick any additional agenda time requests. Thanks, David -----Original Message----- From: Putzolu, David=20 Sent: Monday, October 10, 2005 8:23 AM To: FORCES@PEACH.EASE.LSOFT.COM Cc: 'Patrick Droz' Subject: Call for Agenda Items, ForCES Meeting at IETF 64 All, The ForCES working group is currently scheduled to meet at IETF 64 on Tuesday, November 8 from 1300-1500. Please email agenda time requests to myself and Patrick and include the following information: * Title of presentation or discussion * Expected duration * Presenter name * Related draft(s) * Any slides or other related materials Thanks, David & Patrick From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 20 09:36:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESabJ-0007mh-LB for forces-archive@megatron.ietf.org; Thu, 20 Oct 2005 09:36:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11422 for ; Thu, 20 Oct 2005 09:36:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESanD-0000HO-Qt for forces-archive@IETF.ORG; Thu, 20 Oct 2005 09:49:18 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.011187B1@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 9:36:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88519365 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 09:36:40 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 09:36:35 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9KDYOXK092917 for ; Thu, 20 Oct 2005 06:34:25 -0700 (PDT) Content-Type: multipart/mixed; boundary="=-KN3+Bs6qHdfbIhPqtiX6" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1129815392.6533.91.camel@localhost.localdomain> Date: Thu, 20 Oct 2005 09:36:32 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: updated section 3.2 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 --=-KN3+Bs6qHdfbIhPqtiX6 Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks, I have updated section 3.2 to indicate the down/up states for the FE. This is the last of the know issues. Please comment as i am sure there are a few glitches given the new introduced text and SM. I will upload the new draft somewhere accessible as soon as i see closure on this. The draft will be submitted on sunday to the IETF. cheers, jamal --=-KN3+Bs6qHdfbIhPqtiX6 Content-Disposition: attachment; filename=sec32.txt Content-Type: text/plain; name=sec32.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 3.2. ForCES Protocol Phases ForCES, in relation to NEs, involves two phases: the Pre-Association phase where configuration/initialization/bootup of the TML and PL layer happens, and the association phase where the ForCES protocol operates to manipulate the parameters of the FEs. start FEObject Admin up -------+ +--->---->---->---->------->----+ | | Y Y | | | | Y +------+--+ +--------+ | | | | | DOWN | | UP | | State | | State | | | | | +---------+ +--------+ ^ Y | | +-<---<------<-----<------<----<---+ FEObject Admin Down/ Association lost Figure 4: The FE State Machine The FE can only be in one of two states as indicated above. When the FE is in the DOWN state, it is not forwarding packets. When the FE in the UP state it is forwarding packets. On start up the FE is in the DOWN state unless explicitly configured by the CE to transition to the UP state. This MUST be done before configuring any other LFBs that affect packet forwarding. The FE transitions from the DOWN to the UP state when explicitly configured to do so by the CE or when it looses its association with the CE. It should be noted that what needs to be done for the FE to properly complete the transition to the DOWN state is to stop packet forwarding and that this may affect multiple LFBs. How this is achieved is left as an implementation detail. Doria (Ed.), et al. Expires April 23, 2006 [Page 13] Internet-Draft ForCES October 2005 3.2.1. Pre-association The ForCES interface is configured during the pre-association phase. In a simple setup, the configuration is static and is read from a saved config file. All the parameters for the association phase are well known after the pre-association phase is complete. A protocol such as DHCP may be used to retrieve the config parameters instead of reading them from a static config file. Note, this will still be considered static pre-association. Dynamic configuration may also happen using the Fc, Ff and Fl reference points. Vendors may use their own proprietary service discovery protocol to pass the parameters. Essentially only guidelines are provided here and the details are left to the implementation. The following are scenarios reproduced from the Framework Document to show a pre-association example. <----Ff ref pt---> <--Fc ref pt-------> FE Manager FE CE Manager CE | | | | | | | | (security exchange) (security exchange) 1|<------------>| authentication 1|<----------->|authentication | | | | (FE ID, attributes) (CE ID, attributes) 2|<-------------| request 2|<------------|request | | | | 3|------------->| response 3|------------>|response (corresponding CE ID) (corresponding FE ID) | | | | | | | | Figure 5: Examples of a message exchange over the Ff and Fc reference points Doria (Ed.), et al. Expires April 23, 2006 [Page 14] Internet-Draft ForCES October 2005 <-----------Fl ref pt--------------> | FE Manager FE CE Manager CE | | | | | | | | (security exchange) | | 1|<------------------------------>| | | | | | (a list of CEs and their attributes) | 2|<-------------------------------| | | | | | (a list of FEs and their attributes) | 3|------------------------------->| | | | | | | | | | Figure 6: An example of a message exchange over the Fl reference point Before the transition to the association phase, the FEM will have established contact with the appropriate CEM component. Initialization of the ForCES interface will have completed, and authentication as well as capability discovery may be complete. Both the FE and CE would have the necessary information for connecting to each other for configuration, accounting, identification and authentication purposes. To summarize, at the completion of this stage both sides have all the necessary protocol parameters such as timers, etc. The Fl reference point may continue to operate during the association phase and may be used to force a disassociation of an FE or CE. Because the pre-association phase is out of scope, these details are not discussed any further in this specification. The reader is referred to the framework document [RFC3746] for a slightly more detailed discussion. 3.2.2. Post-association In this phase, the FE and CE components communicate with each other using the ForCES protocol (PL over TML) as defined in this document. There are three sub-phases: o Association Setup stage o Established Stage o Association Lost stage Doria (Ed.), et al. Expires April 23, 2006 [Page 15] Internet-Draft ForCES October 2005 3.2.2.1. Association Setup stage The FE attempts to join the NE. The FE may be rejected or accepted. Once granted access into the NE, capabilities exchange happens with the CE querying the FE. Once the CE has the FE capability information, the CE can offer an initial configuration (possibly to restore state) and can query certain attributes within either an LFB or the FE itself. More details are provided in the protocol scenarios section. On successful completion of this stage, the FE joins the NE and is moved to the Established State. 3.2.2.2. Association Established stage In this stage the FE is continuously updated or queried. The FE may also send asynchronous event notifications to the CE or synchronous heartbeat notifications if programmed to do so. This continues until a termination occurs because of loss of connectivity or is initiated by either the CE or the FE. Refer to section on protocol scenarios Section 7 for more details. 3.2.2.3. Association Lost stage In this state, both or either the CE or FE declare the other side is no longer associated. The disconnection could be physically initiated by either party for administrative purposes but may also be driven by operation reasons such as loss of connectivity. It should be noted that loss of connectivity between TMLs is not necessarily indictive of loss of association between respective PL layers unless the programmed FE Protocol Object time limit is exceeded. In other words if the TML repairs the transport loss before then, the association would still be valid. When an association is lost between a CE and FE, the FE continues to operate as instructed by the CE via the CE failover policy (for further discussion refer to Section 8 and Appendix C). For this revision of the protocol (as defined in this document), the FE, upon re-association, MUST declare all the state it has as invalid and retrieve new state. This approach is motivated by a desire for simplicity (as opposed to efficiency). Doria (Ed.), et al. Expires April 23, 2006 [Page 16] Internet-Draft ForCES October 2005 3.3. Protocol Mechanisms --=-KN3+Bs6qHdfbIhPqtiX6-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 20 10:33:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESbUN-00076v-6y for forces-archive@megatron.ietf.org; Thu, 20 Oct 2005 10:33:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16479 for ; Thu, 20 Oct 2005 10:33:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESbgJ-0002ga-Lw for forces-archive@IETF.ORG; Thu, 20 Oct 2005 10:46:12 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0111883D@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 10:33:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88524236 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 10:33:48 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 10:33:47 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9KEVRXK093275; Thu, 20 Oct 2005 07:31:27 -0700 (PDT) References: <1129815392.6533.91.camel@localhost.localdomain> <00f101c5d57f$a02417d0$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129818815.6168.14.camel@localhost.localdomain> Date: Thu, 20 Oct 2005 10:33:35 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated section 3.2 Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00f101c5d57f$a02417d0$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit On Thu, 2005-20-10 at 22:07 +0800, Wang,Weiming wrote: > Jamal, > > By reading the following text, I have some comments as: > > 1. The FE state and the FE Object LFB state is very different, I think. Note > that we have already mentioned in the FE Object LFB attributes that, the FE > state is only an attribute of FE Object LFB. > > 2. Therefore, we should carefully distinguish the "FE down" state and the "FEO > down" state. They are quite different. I can just see the "FE down" you are > talking about are more "FEO down". I think we should definitely define that > "FE down" is "FE is totally dead", therefore, no way for CE to configure a down > FE to an up FE, whereas we can have "FEO down" state as you described below. > FEObject Admin is intended to imply that the FEStatus attribute of the has been set to bring the FE state to admin up/down. If the text is insufficient, i will change it to explicitly indicate so. See my other email on what bringing an FE0 down would mean. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 20 11:48:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESceY-0006Q0-5v for forces-archive@megatron.ietf.org; Thu, 20 Oct 2005 11:48:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24723 for ; Thu, 20 Oct 2005 11:48:17 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EScqU-0006VW-8P for forces-archive@IETF.ORG; Thu, 20 Oct 2005 12:00:48 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.01118712@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 11:48:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88527365 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 11:48:22 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 11:48:22 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9KFk6XK093896; Thu, 20 Oct 2005 08:46:06 -0700 (PDT) References: <1129815392.6533.91.camel@localhost.localdomain> <00f101c5d57f$a02417d0$1152010a@Necom.hzic.edu.cn> <1129818815.6168.14.camel@localhost.localdomain> <016401c5d58c$45096af0$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129823295.6168.37.camel@localhost.localdomain> Date: Thu, 20 Oct 2005 11:48:15 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated section 3.2 Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <016401c5d58c$45096af0$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit On Thu, 2005-20-10 at 23:38 +0800, Wang,Weiming wrote: > ----- Original Message ----- > From: "Jamal Hadi Salim" > Subject: updated section 3.2 > > The FE can only be in one of two states as indicated above. When the > [Weiming] FE has more state. We'v already defined in one of the "CE failover > policy" that we may allow FE to keep its state and forwad packets continuously > when the FE lost association. > In that case the FE is still up. It is only DOWN when it is not forwarding packets. > FE is in the DOWN state, it is not forwarding packets. When the FE > in the UP state it is forwarding packets. > > On start up the FE is in the DOWN state unless explicitly configured > by the CE to transition to the UP state. This MUST be done before > configuring any other LFBs that affect packet forwarding. > [Weiming] I cannot understand this well. Why the FE is started while it is still > in down state? I can accept that when the FE is booted, the FE is up, but the FE > Object LFB is still in down state. > There is no such thing as FE Object LFB going up or down. There is such a thing as an FE going down/up which is controlled by the FEO FEStatus attribute. When the FE is booted it is in down state because the FEO FEStatus attribute indicates it is. When it has lost association and still forwarding packets, it eventually will stop forwarding packets depending on the policy. When that transition happens, the FE transitions to a DOWN state. > > The FE transitions from the DOWN to the UP state when explicitly > configured to do so by the CE or when it looses its association with > [Weiming] I also cannot understand well that how an FE can be configured when it > is down. This is still more like the FEObject down. > As indicated, the FE starts its state in DOWN. Only when the CE administratively sets the FEO FEStatus attribute does this change. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 20 12:16:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESd5f-0008Jr-TK for forces-archive@megatron.ietf.org; Thu, 20 Oct 2005 12:16:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26531 for ; Thu, 20 Oct 2005 12:16:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESdHb-0007T2-7D for forces-archive@IETF.ORG; Thu, 20 Oct 2005 12:28:50 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0111891E@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 12:16:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88528850 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 12:16:22 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 12:16:22 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9KGE8XK094132; Thu, 20 Oct 2005 09:14:08 -0700 (PDT) References: <1129815392.6533.91.camel@localhost.localdomain> <00f101c5d57f$a02417d0$1152010a@Necom.hzic.edu.cn> <1129818815.6168.14.camel@localhost.localdomain> <016401c5d58c$45096af0$1152010a@Necom.hzic.edu.cn> <1129823295.6168.37.camel@localhost.localdomain> <018101c5d58f$388dbda0$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129824977.6168.46.camel@localhost.localdomain> Date: Thu, 20 Oct 2005 12:16:17 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated section 3.2 Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <018101c5d58f$388dbda0$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit On Thu, 2005-20-10 at 23:59 +0800, Wang,Weiming wrote: > > As indicated, the FE starts its state in DOWN. Only when the CE > > administratively sets the FEO FEStatus attribute does this change. > > So, what is a state of FE before it is started,I mean the state before it is > rebooted(even before pre-association state), 'down' or 'dead'? How can a CE ask > the FE to go to this state? > We can introduce the INIT/DEASSOCIATED state which is entered only once at the beginning. I was trying to avoid doing so. We really have only two states as far as Forces is concerned; it is either associated or not- and this is implicit in the messaging - but since the protocol scenarios had the concept of an FE being told to go up (and Hormuzd siad we had already agreed to have that feature) i agreed to introduce the two explicit states. If an FE is associated then you can apply Forces commands to it. If it is not then you need to associate first before applying such commands. So to make it go back to its old state, you deassociate from it. > I do think the FE down state you talked seems not a complete down state really, > for it seems in this down state, the FE protocol LFB and the FE Object LFB, and > even the TML are still alive, Or else, how can a FE be configured by CE when it > is in down state? > Refer to above please. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 20 13:27:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeC6-0002F0-ET for forces-archive@megatron.ietf.org; Thu, 20 Oct 2005 13:27:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01915 for ; Thu, 20 Oct 2005 13:27:00 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESeO4-0001lo-5p for forces-archive@IETF.ORG; Thu, 20 Oct 2005 13:39:33 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.01118A13@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 13:27:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88536880 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 13:27:07 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 13:27:06 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9KHOsXK094774 for ; Thu, 20 Oct 2005 10:24:54 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1129829224.6168.51.camel@localhost.localdomain> Date: Thu, 20 Oct 2005 13:27:04 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: protocol draft upload To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit People, I have uploaded the latest protocol draft at: ftp://ftp.znyx.com/users/hadi/private/forces/draft-ietf-forces-protocol.txt There is still one outstanding discussion ongoing under the thread "updated section 3.2" which i hope we close and make any necessary changes RealSoonNow. On sunday i will submit this draft to the IETF as version 6. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 20 21:22:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESlbl-0001Vi-Cr for forces-archive@megatron.ietf.org; Thu, 20 Oct 2005 21:22:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14918 for ; Thu, 20 Oct 2005 21:21:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESlnk-0002Cf-FM for forces-archive@IETF.ORG; Thu, 20 Oct 2005 21:34:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.011190BB@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 21:22:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88567305 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 21:21:34 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 21:21:30 -0400 Received: from [70.104.238.60] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12674269; Thu, 20 Oct 2005 19:20:47 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1129815392.6533.91.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051020211943.02ce2468@localhost> Date: Thu, 20 Oct 2005 21:21:28 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: updated section 3.2 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1129815392.6533.91.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 The current wording "When the FE in the UP state it is forwarding packets" seems a little too strong. When the FE is in the UP state, its LFBs can be configured to forward packets? (Not quite right, some FEs probably have a default state that forwards packets to the CE.) When the FE is in the UP state it is not prohibited from forwarding packets? Something like that. Joel At 09:36 AM 10/20/2005, Jamal Hadi Salim wrote: >Folks, >I have updated section 3.2 to indicate the down/up states for the FE. >This is the last of the know issues. Please comment as i am sure there >are a few glitches given the new introduced text and SM. >I will upload the new draft somewhere accessible as soon as i see >closure on this. >The draft will be submitted on sunday to the IETF. > > >cheers, >jamal > From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 21 02:45:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESqeb-0007JF-Jg for forces-archive@megatron.ietf.org; Fri, 21 Oct 2005 02:45:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00549 for ; Fri, 21 Oct 2005 02:45:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESqqe-0003ZJ-Hq for forces-archive@IETF.ORG; Fri, 21 Oct 2005 02:57:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.011197D3@cherry.ease.lsoft.com>; Fri, 21 Oct 2005 2:45:21 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88589712 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Oct 2005 02:45:11 -0400 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 21 Oct 2005 02:45:07 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOP00ATQ734VS@szxga01-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Oct 2005 14:52:16 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOP00ICW73359@szxga01-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Oct 2005 14:52:16 +0800 (CST) Received: from lenovo111 ([10.110.100.34]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOP00HRF75TE2@szxml02-in.huawei.com> for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Oct 2005 14:53:53 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/alternative; boundary="Boundary_(ID_jtvbkf4EAn4QaRZZarf+vg)" X-Priority: 3 X-MSMail-priority: Normal Approved-By: Xiaoyi Guo Message-ID: <02bc01c5d60b$2104bc70$22646e0a@china.huawei.com> Date: Fri, 21 Oct 2005 14:46:13 +0800 Reply-To: Xiaoyi Guo Sender: Forwarding and Control Element Separation From: Xiaoyi Guo Organization: Huawei Tech. Subject: Fwd: I-D ACTION:draft-guo-forces-routing-00.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b This is a multi-part message in MIME format. --Boundary_(ID_jtvbkf4EAn4QaRZZarf+vg) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Here is the draft announcement for the Intra-NE routing mechanism. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-guo-forces-routing-00.txt Best Regards Xiaoyi --Boundary_(ID_jtvbkf4EAn4QaRZZarf+vg) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Here is the draft announcement for the Intra-NE routing mechanism.
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.

>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-guo-forces-routing-00.txt
 
Best Regards
 
Xiaoyi
--Boundary_(ID_jtvbkf4EAn4QaRZZarf+vg)-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 23 12:15:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETiUu-0008RT-H9 for forces-archive@megatron.ietf.org; Sun, 23 Oct 2005 12:15:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13393 for ; Sun, 23 Oct 2005 12:14:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETihQ-0006x7-JC for forces-archive@IETF.ORG; Sun, 23 Oct 2005 12:28:00 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0111BD50@cherry.ease.lsoft.com>; 23 Oct 2005 12:14:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88767777 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 23 Oct 2005 12:14:45 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 23 Oct 2005 12:14:45 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9NGBbXK023045; Sun, 23 Oct 2005 09:11:40 -0700 (PDT) References: <1129829224.6168.51.camel@localhost.localdomain> <01ca01c5d5e8$79d86180$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1130084068.6569.2.camel@localhost.localdomain> Date: Sun, 23 Oct 2005 12:14:28 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: protocol draft upload Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <01ca01c5d5e8$79d86180$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit On Fri, 2005-21-10 at 10:38 +0800, Wang,Weiming wrote: > 6.2.2. FE Object LFB > The FE Object LFB consists of the following elements: > !-- this line is incomplete with no contents followed. Thanks Weiming - fixed by removing that line. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 23 12:17:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETiXB-0000Bm-4M for forces-archive@megatron.ietf.org; Sun, 23 Oct 2005 12:17:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13473 for ; Sun, 23 Oct 2005 12:17:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETijl-00071G-50 for forces-archive@IETF.ORG; Sun, 23 Oct 2005 12:30:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0111BD6E@cherry.ease.lsoft.com>; 23 Oct 2005 12:17:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88767874 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 23 Oct 2005 12:17:18 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 23 Oct 2005 12:17:18 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9NGEOXK023053; Sun, 23 Oct 2005 09:14:25 -0700 (PDT) References: <1129815392.6533.91.camel@localhost.localdomain> <6.2.1.2.0.20051020211943.02ce2468@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1130084235.6569.6.camel@localhost.localdomain> Date: Sun, 23 Oct 2005 12:17:15 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated section 3.2 Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20051020211943.02ce2468@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit On Thu, 2005-20-10 at 21:21 -0400, Joel M. Halpern wrote: > The current wording "When the FE in the UP state it is forwarding packets" > seems a little too strong. > When the FE is in the UP state, its LFBs can be configured to forward > packets? (Not quite right, some FEs probably have a default state that > forwards packets to the CE.) > When the FE is in the UP state it is not prohibited from forwarding packets? > Something like that. Made it to read as: " The FE can only be in one of two states as indicated above. When the FE is in the DOWN state, it is not forwarding packets. When the FE is in the UP state it may be forwarding packets depending on the configuration of its specific LFBs. " cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 23 12:26:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETifr-0002Vm-P1 for forces-archive@megatron.ietf.org; Sun, 23 Oct 2005 12:26:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13896 for ; Sun, 23 Oct 2005 12:26:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETisR-0007J1-4h for forces-archive@IETF.ORG; Sun, 23 Oct 2005 12:39:20 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0111BE83@cherry.ease.lsoft.com>; 23 Oct 2005 12:26:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88768000 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 23 Oct 2005 12:25:27 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 23 Oct 2005 12:25:27 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j9NGMXXK023084 for ; Sun, 23 Oct 2005 09:22:33 -0700 (PDT) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1130084724.6569.14.camel@localhost.localdomain> Date: Sun, 23 Oct 2005 12:25:24 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: draft-ietf-forces-protocol-05.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Folks, I have uploaded the latest revision of the draft at: ftp://ftp.znyx.com/users/hadi/private/forces/draft-ietf-forces-protocol-05.txt This draft will be submitted in a few hours. If there are any issues, please post ASAP otherwise go to the tracker and make an entry. We consider this draft stable for the protocol. In other words there are no controversial issues - any future changes are going to be mechanical. There is desire to go to Last Call with this draft as a basis so please read carefully and comment. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 23 12:30:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETijl-0004XC-HQ for forces-archive@megatron.ietf.org; Sun, 23 Oct 2005 12:30:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14064 for ; Sun, 23 Oct 2005 12:30:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETiwH-0007P2-Qm for forces-archive@IETF.ORG; Sun, 23 Oct 2005 12:43:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0111BD06@cherry.ease.lsoft.com>; 23 Oct 2005 12:30:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88768234 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 23 Oct 2005 12:30:15 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 23 Oct 2005 12:30:15 -0400 Received: from [162.83.103.62] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12677832 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 23 Oct 2005 10:29:29 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1129815392.6533.91.camel@localhost.localdomain> <6.2.1.2.0.20051020211943.02ce2468@localhost> <1130084235.6569.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051023122957.02d2b030@localhost> Date: Sun, 23 Oct 2005 12:30:13 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: updated section 3.2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1130084235.6569.6.camel@localhost.localdomain> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Works for me. Thanks. Joel At 12:17 PM 10/23/2005, Jamal Hadi Salim wrote: >On Thu, 2005-20-10 at 21:21 -0400, Joel M. Halpern wrote: > > The current wording "When the FE in the UP state it is forwarding packets" > > seems a little too strong. > > When the FE is in the UP state, its LFBs can be configured to forward > > packets? (Not quite right, some FEs probably have a default state that > > forwards packets to the CE.) > > When the FE is in the UP state it is not prohibited from forwarding > packets? > > Something like that. > >Made it to read as: > >" The FE can only be in one of two states as indicated above. When >the FE is in the DOWN state, it is not forwarding packets. When the FE >is in the UP state it may be forwarding packets depending on the >configuration of its specific LFBs. >" > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 24 11:25:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4Cq-0002lC-0d for forces-archive@megatron.ietf.org; Mon, 24 Oct 2005 11:25:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15353 for ; Mon, 24 Oct 2005 11:25:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU4PW-0007Oo-Ot for forces-archive@IETF.ORG; Mon, 24 Oct 2005 11:39:00 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0111CC8B@cherry.ease.lsoft.com>; Mon, 24 Oct 2005 10:52:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88828256 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Oct 2005 10:52:07 -0400 Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 24 Oct 2005 10:51:52 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j9OEppZB118782 for ; Mon, 24 Oct 2005 14:51:51 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9OEpocf209238 for ; Mon, 24 Oct 2005 16:51:50 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j9OEpo5B023770 for ; Mon, 24 Oct 2005 16:51:50 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j9OEpo1U023755 for ; Mon, 24 Oct 2005 16:51:50 +0200 Received: from [127.0.0.1] (dhcp71-149.zurich.ibm.com [9.4.71.149]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA76682 for ; Mon, 24 Oct 2005 16:51:49 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <434BB83B.5050100@zurich.ibm.com> <434E7051.4080500@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id j9OEppZB118782 Approved-By: Robert Haas Message-ID: <435CF506.1000106@zurich.ibm.com> Date: Mon, 24 Oct 2005 16:51:50 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: ForCES MIB: 1st draft To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <434E7051.4080500@zurich.ibm.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Hi All, The -00 version of the ForCES MIB draft is in the repository: http://www.ietf.org/internet-drafts/draft-haas-forces-mib-00.txt Comments and contributions welcome. Regards, -Robert --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 24 12:34:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5HF-0001vH-Mk for forces-archive@megatron.ietf.org; Mon, 24 Oct 2005 12:34:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19163 for ; Mon, 24 Oct 2005 12:34:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU5Tz-0001JJ-KA for forces-archive@IETF.ORG; Mon, 24 Oct 2005 12:47:38 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0111CE51@cherry.ease.lsoft.com>; Mon, 24 Oct 2005 12:34:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88856729 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Oct 2005 12:34:11 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 24 Oct 2005 12:34:11 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9OGYAG4022075 for ; Mon, 24 Oct 2005 16:34:10 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9OGXdOO016309 for ; Mon, 24 Oct 2005 16:34:10 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005102409321711608 for ; Mon, 24 Oct 2005 09:32:19 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Oct 2005 09:28:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: Updated draft agenda, call for agenda items, ForCES meeting at IETF 64 thread-index: AcXNrniqEI+3Fok0QnqHKKO9qyvRzAGhQGbAASEXUWA= X-OriginalArrivalTime: 24 Oct 2005 16:28:39.0641 (UTC) FILETIME=[FDAB6490:01C5D8B7] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Putzolu, David" Message-ID: Date: Mon, 24 Oct 2005 09:28:39 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Updated draft agenda, call for agenda items, ForCES meeting at IETF 64 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable All, The draft agenda for the ForCES meeting at IETF 64 has been updated and can be found at the following address: http://www3.ietf.org/proceedings/05nov/agenda/forces.txt Please email me and Patrick any additional agenda time requests. Thanks, David =20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David Sent: Tuesday, October 18, 2005 3:31 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Call for Agenda Items, ForCES Meeting at IETF 64 All, The draft agenda for the ForCES meeting at IETF 64 can be found at the following address: http://www3.ietf.org/proceedings/05nov/agenda/forces.txt=20 Please email me and Patrick any additional agenda time requests. Thanks, David -----Original Message----- From: Putzolu, David=20 Sent: Monday, October 10, 2005 8:23 AM To: FORCES@PEACH.EASE.LSOFT.COM Cc: 'Patrick Droz' Subject: Call for Agenda Items, ForCES Meeting at IETF 64 All, The ForCES working group is currently scheduled to meet at IETF 64 on Tuesday, November 8 from 1300-1500. Please email agenda time requests to myself and Patrick and include the following information: * Title of presentation or discussion * Expected duration * Presenter name * Related draft(s) * Any slides or other related materials Thanks, David & Patrick From owner-forces@PEACH.EASE.LSOFT.COM Tue Oct 25 09:06:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUOVI-0006ud-Ij for forces-archive@megatron.ietf.org; Tue, 25 Oct 2005 09:06:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15628 for ; Tue, 25 Oct 2005 09:05:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUOiE-00022E-69 for forces-archive@IETF.ORG; Tue, 25 Oct 2005 09:19:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0111E250@cherry.ease.lsoft.com>; Tue, 25 Oct 2005 9:06:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88944486 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Oct 2005 09:06:07 -0400 Received: from 62.241.163.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 25 Oct 2005 09:06:07 -0400 Received: from pc6 (1Cust149.tnt3.lnd4.gbr.da.uu.net [62.188.132.149]) by blaster.systems.pipex.net (Postfix) with SMTP id 394A2E0001FC; Tue, 25 Oct 2005 14:06:05 +0100 (BST) References: <434BB83B.5050100@zurich.ibm.com> <434E7051.4080500@zurich.ibm.com> <435CF506.1000106@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable Approved-By: Tom Petch Message-ID: <096e01c5d95c$50b0a660$0601a8c0@pc6> Date: Tue, 25 Oct 2005 12:51:41 +0200 Reply-To: Tom Petch Sender: Forwarding and Control Element Separation From: Tom Petch Subject: Re: ForCES MIB: 1st draft Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable I would have thought there was a need for an NE MIB which has a table giv= ing details of the CE and FE, their ids, capabilities and so on, rather than inferring that from a list of associations Tom Petch ----- Original Message ----- From: "Robert Haas" To: Sent: Monday, October 24, 2005 4:51 PM Subject: Re: ForCES MIB: 1st draft Hi All, The -00 version of the ForCES MIB draft is in the repository: http://www.ietf.org/internet-drafts/draft-haas-forces-mib-00.txt Comments and contributions welcome. Regards, -Robert -- Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From jslater@algavista.com Tue Oct 25 14:47:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTq0-0006Lt-Nt for forces-archive@megatron.ietf.org; Tue, 25 Oct 2005 14:47:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12068 for ; Tue, 25 Oct 2005 14:47:41 -0400 (EDT) Received: from wt.infoteck.com.br ([200.178.176.130] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUU2a-0005tA-9Z for forces-archive@ietf.org; Tue, 25 Oct 2005 15:01:22 -0400 Message-ID: <000001c5d992$e88e0000$0100007f@localhost> From: "Payton Gonzales" To: Subject: cheap oem soft shipping //orldwide Date: Tue, 25 Oct 2005 18:46:52 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5D992.E88E0000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5D992.E88E0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5D992.E88E0000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 48 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 37 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 38 reviews)

------=_NextPart_000_0001_01C5D992.E88E0000-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Oct 25 20:31:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUZCs-0001t8-JN for forces-archive@megatron.ietf.org; Tue, 25 Oct 2005 20:31:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09461 for ; Tue, 25 Oct 2005 20:31:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUZPp-0004HX-LA for forces-archive@IETF.ORG; Tue, 25 Oct 2005 20:45:24 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0111F161@cherry.ease.lsoft.com>; Tue, 25 Oct 2005 20:30:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88991977 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Oct 2005 20:30:49 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 25 Oct 2005 20:30:49 -0400 Received: from [162.83.103.62] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12681892; Tue, 25 Oct 2005 18:30:00 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <434BB83B.5050100@zurich.ibm.com> <434E7051.4080500@zurich.ibm.com> <435CF506.1000106@zurich.ibm.com> <096e01c5d95c$50b0a660$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051025202624.030b6150@localhost> Date: Tue, 25 Oct 2005 20:30:49 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: ForCES MIB: 1st draft Comments: To: Tom Petch To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <096e01c5d95c$50b0a660$0601a8c0@pc6> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable I would hope we don't try to duplicate all the ForCES information into the= MIB. While one could imagine trying to use SNMP to remotely control a CE, so as= =20 to control the FE, I had thought that was not the goal. Hence, the ForCES MIB is about control the protocol, not the model=20 objects. It would report, as seen by the CE, what the protocol is=20 doing. (I would expect it to include some of the statistics Robert refers= =20 to in his Note.) If we want to allow "set"s at all, I suppose we could allow setting the=20 heartbeat interval. We might want to make visible a view FE attributes like the FE=20 understanding of the protocol version. But I hope we are not going to try to get the LFB support information, LFB= =20 topology, etc into the MIB. Yours, Joel At 06:51 AM 10/25/2005, Tom Petch wrote: >I would have thought there was a need for an NE MIB which has a table= giving >details of the CE and FE, their ids, capabilities and so on, rather than >inferring that from a list of associations > >Tom Petch > >----- Original Message ----- >From: "Robert Haas" >To: >Sent: Monday, October 24, 2005 4:51 PM >Subject: Re: ForCES MIB: 1st draft > > >Hi All, >The -00 version of the ForCES MIB draft is in the repository: > >http://www.ietf.org/internet-drafts/draft-haas-forces-mib-00.txt > >Comments and contributions welcome. > >Regards, >-Robert > >-- >Dr. Robert R. Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Tue Oct 25 21:02:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUZgc-0003b8-4z for forces-archive@megatron.ietf.org; Tue, 25 Oct 2005 21:02:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10795 for ; Tue, 25 Oct 2005 21:02:23 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUZte-000503-2m for forces-archive@IETF.ORG; Tue, 25 Oct 2005 21:16:08 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0111F104@cherry.ease.lsoft.com>; Tue, 25 Oct 2005 21:02:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88994151 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Oct 2005 21:02:33 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 25 Oct 2005 21:02:33 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9Q12Wqv016980; Wed, 26 Oct 2005 01:02:32 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9Q12MMr032717; Wed, 26 Oct 2005 01:02:32 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005102518023031563 ; Tue, 25 Oct 2005 18:02:30 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 18:02:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] ForCES MIB: 1st draft thread-index: AcXZxKR/OSqaGPDkRKCG6maSOTAyXAABBJyA X-OriginalArrivalTime: 26 Oct 2005 01:02:30.0281 (UTC) FILETIME=[F0937790:01C5D9C8] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E072CFE41@orsmsx408> Date: Tue, 25 Oct 2005 18:02:28 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES MIB: 1st draft Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable I believe this is what the MIB is doing...I just looked at the MIB = draft. It looks like a good design to me though there are lots of editorial = problems with the draft itself. Good work Robert! Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, October 25, 2005 5:31 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES MIB: 1st draft I would hope we don't try to duplicate all the ForCES information into = the MIB. While one could imagine trying to use SNMP to remotely control a CE, so = as=20 to control the FE, I had thought that was not the goal. Hence, the ForCES MIB is about control the protocol, not the model=20 objects. It would report, as seen by the CE, what the protocol is=20 doing. (I would expect it to include some of the statistics Robert = refers=20 to in his Note.) If we want to allow "set"s at all, I suppose we could allow setting the=20 heartbeat interval. We might want to make visible a view FE attributes like the FE=20 understanding of the protocol version. But I hope we are not going to try to get the LFB support information, = LFB=20 topology, etc into the MIB. Yours, Joel At 06:51 AM 10/25/2005, Tom Petch wrote: >I would have thought there was a need for an NE MIB which has a table = giving >details of the CE and FE, their ids, capabilities and so on, rather = than >inferring that from a list of associations > >Tom Petch > >----- Original Message ----- >From: "Robert Haas" >To: >Sent: Monday, October 24, 2005 4:51 PM >Subject: Re: ForCES MIB: 1st draft > > >Hi All, >The -00 version of the ForCES MIB draft is in the repository: > >http://www.ietf.org/internet-drafts/draft-haas-forces-mib-00.txt > >Comments and contributions welcome. > >Regards, >-Robert > >-- >Dr. Robert R. Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-44-724-8698 fax +41-44-724-8578 = http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 26 06:18:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiMd-0006l5-8D for forces-archive@megatron.ietf.org; Wed, 26 Oct 2005 06:18:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09339 for ; Wed, 26 Oct 2005 06:18:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUiZk-0004EZ-2I for forces-archive@IETF.ORG; Wed, 26 Oct 2005 06:32:10 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0111FAC1@cherry.ease.lsoft.com>; Wed, 26 Oct 2005 6:18:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89028441 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 06:18:14 -0400 Received: from 62.241.162.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 26 Oct 2005 06:18:14 -0400 Received: from pc6 (1Cust93.tnt29.lnd3.gbr.da.uu.net [62.188.120.93]) by ranger.systems.pipex.net (Postfix) with SMTP id 3AE1EE000243; Wed, 26 Oct 2005 11:18:12 +0100 (BST) References: <434BB83B.5050100@zurich.ibm.com> <434E7051.4080500@zurich.ibm.com> <435CF506.1000106@zurich.ibm.com> <096e01c5d95c$50b0a660$0601a8c0@pc6> <6.2.1.2.0.20051025202624.030b6150@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Tom Petch Message-ID: <03ff01c5da0e$06898400$0601a8c0@pc6> Date: Wed, 26 Oct 2005 11:16:17 +0200 Reply-To: Tom Petch Sender: Forwarding and Control Element Separation From: Tom Petch Subject: Re: ForCES MIB: 1st draft Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit I agree with the idea that the MIB is not about control and am happy with it being read only. What I do find strange is having a table of associations, which are identified by ids for CE and FE, and that that is all that is visible about CE and FE; I think there should be a separate table, at the NE level, giving ids, whether or not they are in an association at present. Having only associations is a bit like viewing the Internet from a default free routing table, being unaware of links etc that are not currently preferred ones. Tom Petch ----- Original Message ----- From: "Joel M. Halpern" To: "Tom Petch" ; Sent: Wednesday, October 26, 2005 2:30 AM Subject: Re: ForCES MIB: 1st draft I would hope we don't try to duplicate all the ForCES information into the MIB. While one could imagine trying to use SNMP to remotely control a CE, so as to control the FE, I had thought that was not the goal. Hence, the ForCES MIB is about control the protocol, not the model objects. It would report, as seen by the CE, what the protocol is doing. (I would expect it to include some of the statistics Robert refers to in his Note.) If we want to allow "set"s at all, I suppose we could allow setting the heartbeat interval. We might want to make visible a view FE attributes like the FE understanding of the protocol version. But I hope we are not going to try to get the LFB support information, LFB topology, etc into the MIB. Yours, Joel At 06:51 AM 10/25/2005, Tom Petch wrote: >I would have thought there was a need for an NE MIB which has a table giving >details of the CE and FE, their ids, capabilities and so on, rather than >inferring that from a list of associations > >Tom Petch > From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 26 10:10:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlzG-0005MR-F1 for forces-archive@megatron.ietf.org; Wed, 26 Oct 2005 10:10:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22202 for ; Wed, 26 Oct 2005 10:10:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUmCQ-00033o-D5 for forces-archive@IETF.ORG; Wed, 26 Oct 2005 10:24:19 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0111FB96@cherry.ease.lsoft.com>; Wed, 26 Oct 2005 10:10:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89041857 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 10:10:34 -0400 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 26 Oct 2005 10:10:34 -0400 Received: from [162.83.103.62] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12682877 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 08:09:44 -0600 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <434BB83B.5050100@zurich.ibm.com> <434E7051.4080500@zurich.ibm.com> <435CF506.1000106@zurich.ibm.com> <096e01c5d95c$50b0a660$0601a8c0@pc6> <6.2.1.2.0.20051025202624.030b6150@localhost> <03ff01c5da0e$06898400$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051026100747.030a2060@localhost> Date: Wed, 26 Oct 2005 10:10:31 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: ForCES MIB: 1st draft To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <03ff01c5da0e$06898400$0601a8c0@pc6> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a I must be misunderstanding what you are asking for. I don't know how the SNMP could be "at the NE level". As I understand it, from a ForCES protocol perspective, here is no NE to talk to. The SNMP is being exchanged with a specific CE. It may not even know about other CEs which are, from the operational perspective, part of the same NE. From the CE Manager or FE Manager there is presumably knowledge of the NE. But we are not defining the CEM and FEM. Yours, Joel At 05:16 AM 10/26/2005, Tom Petch wrote: >I agree with the idea that the MIB is not about control and am happy with it >being read only. What I do find strange is having a table of associations, >which are identified by ids for CE and FE, and that that is all that is >visible >about CE and FE; I think there should be a separate table, at the NE level, >giving ids, whether or not they are in an association at present. > >Having only associations is a bit like viewing the Internet from a default >free >routing table, being unaware of links etc that are not currently preferred >ones. > >Tom Petch > >----- Original Message ----- >From: "Joel M. Halpern" >To: "Tom Petch" ; >Sent: Wednesday, October 26, 2005 2:30 AM >Subject: Re: ForCES MIB: 1st draft > > >I would hope we don't try to duplicate all the ForCES information into the >MIB. >While one could imagine trying to use SNMP to remotely control a CE, so as >to control the FE, I had thought that was not the goal. > >Hence, the ForCES MIB is about control the protocol, not the model >objects. It would report, as seen by the CE, what the protocol is >doing. (I would expect it to include some of the statistics Robert refers >to in his Note.) >If we want to allow "set"s at all, I suppose we could allow setting the >heartbeat interval. >We might want to make visible a view FE attributes like the FE >understanding of the protocol version. > >But I hope we are not going to try to get the LFB support information, LFB >topology, etc into the MIB. > > >Yours, >Joel > >At 06:51 AM 10/25/2005, Tom Petch wrote: > >I would have thought there was a need for an NE MIB which has a table giving > >details of the CE and FE, their ids, capabilities and so on, rather than > >inferring that from a list of associations > > > >Tom Petch > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 26 11:25:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUn9e-0000qz-KI for forces-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:25:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01023 for ; Wed, 26 Oct 2005 11:25:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnMp-0006yp-PW for forces-archive@IETF.ORG; Wed, 26 Oct 2005 11:39:08 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0111FC6D@cherry.ease.lsoft.com>; Wed, 26 Oct 2005 11:25:28 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89049587 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 11:25:28 -0400 Received: from 62.241.163.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 26 Oct 2005 11:25:28 -0400 Received: from pc6 (1Cust219.tnt16.lnd4.gbr.da.uu.net [62.188.145.219]) by astro.systems.pipex.net (Postfix) with SMTP id CFFFFE00017E; Wed, 26 Oct 2005 16:25:25 +0100 (BST) References: <434BB83B.5050100@zurich.ibm.com> <434E7051.4080500@zurich.ibm.com> <435CF506.1000106@zurich.ibm.com> <096e01c5d95c$50b0a660$0601a8c0@pc6> <6.2.1.2.0.20051025202624.030b6150@localhost> <03ff01c5da0e$06898400$0601a8c0@pc6> <6.2.1.2.0.20051026100747.030a2060@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Tom Petch Message-ID: <014301c5da38$f13a9820$0601a8c0@pc6> Date: Wed, 26 Oct 2005 16:23:57 +0200 Reply-To: Tom Petch Sender: Forwarding and Control Element Separation From: Tom Petch Subject: Re: ForCES MIB: 1st draft Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit By NE MIB, I was meaning the second of the two choices in the draft, namely, 2) single NE MIB An entity in the NE implements an NE MIB that aggregates state information collected from each CE (CEs are possibly from various vendors). This requires a standard protocol in order to support multi-vendor environment. AgentX with the NE as the master and the CE(s) as the agent(s) may be considered here. seeing that as preferrable to the alternative, CE MIB. But whichever there is, I would still hope to see the FE and CE in some more detail than just IDs in the association table knowing only, from the ID itself, which is CE and which is FE. I had in mind the sort of information contained in the system group of mib-2. Tom Petch ----- Original Message ----- From: "Joel M. Halpern" To: Sent: Wednesday, October 26, 2005 4:10 PM Subject: Re: ForCES MIB: 1st draft > I must be misunderstanding what you are asking for. > I don't know how the SNMP could be "at the NE level". As I understand it, > from a ForCES protocol perspective, here is no NE to talk to. The SNMP is > being exchanged with a specific CE. It may not even know about other CEs > which are, from the operational perspective, part of the same NE. From the > CE Manager or FE Manager there is presumably knowledge of the NE. But we > are not defining the CEM and FEM. > > Yours, > Joel > > At 05:16 AM 10/26/2005, Tom Petch wrote: > >I agree with the idea that the MIB is not about control and am happy with it > >being read only. What I do find strange is having a table of associations, > >which are identified by ids for CE and FE, and that that is all that is > >visible > >about CE and FE; I think there should be a separate table, at the NE level, > >giving ids, whether or not they are in an association at present. > > > >Having only associations is a bit like viewing the Internet from a default > >free > >routing table, being unaware of links etc that are not currently preferred > >ones. > > > >Tom Petch > > > >----- Original Message ----- > >From: "Joel M. Halpern" > >To: "Tom Petch" ; > >Sent: Wednesday, October 26, 2005 2:30 AM > >Subject: Re: ForCES MIB: 1st draft > > > > > >I would hope we don't try to duplicate all the ForCES information into the > >MIB. > >While one could imagine trying to use SNMP to remotely control a CE, so as > >to control the FE, I had thought that was not the goal. > > > >Hence, the ForCES MIB is about control the protocol, not the model > >objects. It would report, as seen by the CE, what the protocol is > >doing. (I would expect it to include some of the statistics Robert refers > >to in his Note.) > >If we want to allow "set"s at all, I suppose we could allow setting the > >heartbeat interval. > >We might want to make visible a view FE attributes like the FE > >understanding of the protocol version. > > > >But I hope we are not going to try to get the LFB support information, LFB > >topology, etc into the MIB. > > > > > >Yours, > >Joel > > > >At 06:51 AM 10/25/2005, Tom Petch wrote: > > >I would have thought there was a need for an NE MIB which has a table giving > > >details of the CE and FE, their ids, capabilities and so on, rather than > > >inferring that from a list of associations > > > > > >Tom Petch > > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 28 02:06:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVNNd-0004m8-Hx for forces-archive@megatron.ietf.org; Fri, 28 Oct 2005 02:06:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23786 for ; Fri, 28 Oct 2005 02:06:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVNb2-00024B-Of for forces-archive@IETF.ORG; Fri, 28 Oct 2005 02:20:17 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.01121EDB@cherry.ease.lsoft.com>; Fri, 28 Oct 2005 2:05:51 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89206361 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 28 Oct 2005 02:05:49 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 28 Oct 2005 02:05:48 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9S65lwm002126 for ; Fri, 28 Oct 2005 06:05:47 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9S65eNJ003177 for ; Fri, 28 Oct 2005 06:05:47 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005102723054707806 for ; Thu, 27 Oct 2005 23:05:47 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 23:05:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DB85.A39A2CD0" Thread-Topic: TML data channel transport protocol choice? thread-index: AcXbhaRJI9MwJnP2RPWh6GmXBwubEQ== X-OriginalArrivalTime: 28 Oct 2005 06:05:47.0340 (UTC) FILETIME=[A3B1D0C0:01C5DB85] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E07348177@orsmsx408> Date: Thu, 27 Oct 2005 23:05:48 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.2 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DB85.A39A2CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 I would like to know what thoughts the WG has on the data channel transport for the TCP/IP TML that is the default ForCES TML. This is the main issue remaining before we can take this draft to WG LC. =20 There are couple of options available for the data channel transport protocol: =20 TCP - This would work well with the TCP connection that is used for the control channel. However, there are issues around behavior with routing protocols such as BGP that themselves use TCP. =20 DCCP - This is the best theoretical option in terms of the properties it possesses, i.e. no-reliable transport protocol with Congestion Control (CC). The only issue with this in the past has bee lack of stable implementations. But this was over a year back when I was doing some experiments, I have been told that this is no longer the case. =20 UDP with some sort of rate limiting or CC - This option would essentially be reinventing the wheel in terms of what has been done with DCCP to some extent, unless we can find a straight forward way to do this. Also, co-existence with TCP CC mechanism used by control channel is unknown. =20 I would like to hear from the WG at this point. If we can reach a rough consensus soon, that would be great. =20 =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C5DB85.A39A2CD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

I would like to know what thoughts the WG has on the = data channel transport for the TCP/IP TML that is the default ForCES = TML.

This is the main issue remaining before we can take = this draft to WG LC.

 

There are couple of options available for the data = channel transport protocol:

 

TCP – This would work well with the TCP = connection that is used for the control channel. However, there are issues around = behavior with routing protocols such as BGP that themselves use = TCP.

 

DCCP – This is the best theoretical option in = terms of the properties it possesses, i.e. no-reliable transport protocol with Congestion Control (CC). The only issue with this in the past has bee = lack of stable implementations. But this was over a year back when I was doing = some experiments, I have been told that this is no longer the = case.

 

UDP with some sort of rate limiting or CC – = This option would essentially be reinventing the wheel in terms of what has = been done with DCCP to some extent, unless we can find a straight forward way = to do this. Also, co-existence with TCP CC mechanism used by control channel = is unknown.

 

I would like to hear from the WG at this point. If we = can reach a rough consensus soon, that would be great.

 

 

Thanks

Hormuzd

 

------_=_NextPart_001_01C5DB85.A39A2CD0-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 28 13:38:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVYBn-0001Ft-Dt for forces-archive@megatron.ietf.org; Fri, 28 Oct 2005 13:38:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00110 for ; Fri, 28 Oct 2005 13:38:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVYPP-0004a7-3D for forces-archive@IETF.ORG; Fri, 28 Oct 2005 13:52:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0112241B@cherry.ease.lsoft.com>; Fri, 28 Oct 2005 13:38:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89273502 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 28 Oct 2005 13:38:46 -0400 Received: from 62.241.162.31 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 28 Oct 2005 13:38:45 -0400 Received: from pc6 (1Cust10.tnt106.lnd4.gbr.da.uu.net [213.116.60.10]) by galaxy.systems.pipex.net (Postfix) with SMTP id 116E0E000241; Fri, 28 Oct 2005 18:38:42 +0100 (BST) References: <434BB83B.5050100@zurich.ibm.com> <434E7051.4080500@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Tom Petch Message-ID: <052401c5dbdd$e2fe5020$0601a8c0@pc6> Date: Fri, 28 Oct 2005 18:36:37 +0200 Reply-To: Tom Petch Sender: Forwarding and Control Element Separation From: Tom Petch Subject: DateTime was Re: ForCES MIB: 1st draft Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: 7bit One issue I am curious about is the choice of Date/Time for the associations' up time. SNMP requires every agent to have a clock but only an relative time clock with a resolution of TimeTicks (0.01s), not a ToD clock. The onus is then on the SNMP manager to synchronise these relative times and make them absolute when needed. Why choose DateTime and where is this coming from? (NTP:-) What resolution is needed? If there are multiple clocks with an NE, how are they synchronised? Even, is there a need for a protocol within the NE for this? (not saying there is but it is possible depending on the other answers). Tom Petch ----- Original Message ----- From: "Robert Haas" To: Sent: Thursday, October 13, 2005 4:33 PM Subject: Re: ForCES MIB: 1st draft > All, > > Below is the 1st draft, which raises a few issues. > > Regards, > -Robert > > > > ForCES MIB > > (draft version 00-a) > > 0. Abstract > > This document specifies the ForCES MIB. > > > 1. Introduction > > The ForCES MIB is a read-only MIB that captures information related to > the ForCES protocol. This includes state information about the > associations between CE(s) and FE(s) in the NE. > [Note: anything else besides associations that the MIB should include?] > > The ForCES MIB does not include information that is specified in other > MIBs, such as packet counters for interfaces, etc. > > The information in the ForCES MIB relative to associations includes more > specifically: > > - identifiers of the elements in the association > - state of the association > - configuration parameters of the association > - statistics of the association > > The relevant references from the ForCES requirements and architecture > documents are repeated below: > > Requirements RFC 3654 http://www.ietf.org/rfc/rfc3654.txt > Section 4, point 4: > 4) A NE MUST support the appearance of a single functional device. > For example, in a router, the TTL of the packet should be decremented > only once as it traverses the NE regardless of how many FEs through > which it passes. However, external entities (e.g., FE managers and > CE managers) MAY have direct access to individual ForCES protocol > elements for providing information to transition them from the pre- > association to post-association phase. > > Section 4, point 14: > 1. The ability for a management tool (e.g., SNMP) to be used to read > (but not change) the state of FE SHOULD NOT be precluded. > 2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to > change the state of a FE in a manner that affects overall NE > behavior without the CE being notified. > > Architecture RFC 3746 http://www.ietf.org/rfc/rfc3746.txt > Section 3.3: > CE managers may be physically and logically separate > entities that configure the CE with FE information via such > mechanisms as COPS-PR [7] or SNMP [5]. > > Section 5.7: > 5.7. Application Layer -- Network Management Protocol > > RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP". > In general, for the post-association phase, most external management > tasks (including SNMP) should be done through interaction with the CE > in order to support the appearance of a single functional device. > Therefore, it is recommended that an SNMP agent be implemented by CEs > and that the SNMP messages received by FEs be redirected to their > CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here > such that CEs act in the role of master agent to process SNMP > protocol messages while FEs act in the role of subagent to provide > access to the MIB objects residing on FEs. AgentX protocol messages > between the master agent (CE) and the subagent (FE) are encapsulated > and transported via ForCES, just like data packets from any other > application layer protocols. > > > > 2. Design of ForCES MIB > > As state information is distributed across FEs and CEs, the following > alternatives may be considered: > > 1) CE MIBs > Each CE in the NE implements a CE MIB. The external SNMP-based > management tool must therefore be aware of each CE in order to obtain a > complete view of the NE by collecting state information obtained from > each CE MIB. > [Note: this may or may not comply with requirement #4 ("A NE MUST > support the appearance of a single functional device")] > > 2) single NE MIB > An entity in the NE implements an NE MIB that aggregates state > information collected from each CE (CEs are possibly from various > vendors). This requires a standard protocol in order to support > multi-vendor environment. AgentX with the NE as the master and the CE(s) > as the agent(s) may be considered here. > [Note: comments on the suitability of AgentX ?] > > [Note: none of the two alternatives are ideal ...] > > 3. Capturing State Before Association Establishment > > The ForCES protocol may be used by the CE to query the FE Protocol LFB > about some of the configuration parameters. But such queries may > obviously be issued only once the association is established. > > In the ForCES protocol, the FE first issues an Association Setup Request > message to the CE which in turns responds with an Association Setup > Response message. It may be useful to capture in the MIB in which state > the association is seen from each of the FE and the CE sides, as a means > to detect PL-level communication anomalies. For instance, from the FE > side, the association is in the ATTEMPT state as long as no response to > the Association Setup message has been received from the CE. Similarly, > the association is in the ESTABLISHING state as long as no message has > been received from the FE after the CE has issued a positive Association > Setup Response message (this is because configuration mistakes in the FE > may cause messages from the CE to be ignored, and the MIB could help in > tracing such errors). > > The transient state in the FE until the association is established > cannot be queried using ForCES. > [Note: If such information is critical, then an FE MIB has to be > provided that can be queried separately] > > > 4. MIB Definition(s) > > For each association identified by the pair CE ID and FE ID, the > following information is included in the MIB: > > [Note: the MIB includes all associations for the particular CE in the > case of a CE MIB, same for FE MIBs (if any), or all associations in the > NE in the case of a NE MIB] > > - Current state of the association: > > UP: the CE(s) indicated by the CE ID and FE(s) indicated by > the FE ID are associated. > ESTABLISHING/ATTEMPT: transient state unitl the association is > established. See section 3 above for details. > > Note that associations that are not UP and for which no association > setup is in progress are NOT listed in the MIB. > [Note: otherwise how do we decide which old associations to remove from > the MIB ?] > > - Hearbeat timers values of the FE and CE for this association. > > - Heartbeat timer settings of the FE and CE for this association: > > ENABLED: hearbeats are transmitted (by default virtual piggybacking > is used) > DISABLED: heartbeats are not transmitted > > - Backup information: the FE(s)/CE(s) that are configured to work as > backups for this association. > [Note: is this necessary, useful ?] > > - Association statistics: > Date/time when the association came to the UP state. > [Note: what about the Number of commands executed or some indications of > the ForCES control traffic ?] > > > TBD: actual MIB specification. From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 28 22:08:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVg8y-0001GC-KH for forces-archive@megatron.ietf.org; Fri, 28 Oct 2005 22:08:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03270 for ; Fri, 28 Oct 2005 22:08:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVgMa-00048y-Km for forces-archive@IETF.ORG; Fri, 28 Oct 2005 22:22:37 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.011229DC@cherry.ease.lsoft.com>; Fri, 28 Oct 2005 22:08:21 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89315754 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 28 Oct 2005 22:08:17 -0400 Received: from 209.119.0.160 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 28 Oct 2005 22:08:17 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.0096F06A@almond.ease.lsoft.com>; Fri, 28 Oct 2005 22:08:17 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Message-ID: Date: Fri, 28 Oct 2005 22:08:13 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable hi,=20 We have done some experiments to check the performance of TML. Hope we can=20 discuss it during this IETF conference. regards Ligang ----- Original Message -----=20 From: Khosravi, Hormuzd M=20 To: FORCES@PEACH.EASE.LSOFT.COM=20 Sent: Friday, October 28, 2005 2:05 PM Subject: TML data channel transport protocol choice? Hi Folks, =20 I would like to know what thoughts the WG has on the data channel transport = for the TCP/IP TML that is the default ForCES TML. This is the main issue remaining before we can take this draft to WG LC. =20 There are couple of options available for the data channel transport=20 protocol: =20 TCP =A8C This would work well with the TCP connection that is used for the=20 control channel. However, there are issues around behavior with routing=20 protocols such as BGP that themselves use TCP. =20 DCCP =A8C This is the best theoretical option in terms of the properties it = possesses, i.e. no-reliable transport protocol with Congestion Control=20 (CC). The only issue with this in the past has bee lack of stable=20 implementations. But this was over a year back when I was doing some=20 experiments, I have been told that this is no longer the case. =20 UDP with some sort of rate limiting or CC =A8C This option would essentially= =20 be reinventing the wheel in terms of what has been done with DCCP to some=20 extent, unless we can find a straight forward way to do this. Also, co- existence with TCP CC mechanism used by control channel is unknown. =20 I would like to hear from the WG at this point. If we can reach a rough=20 consensus soon, that would be great. =20 =20 Thanks Hormuzd =20 From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 28 23:04:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVh0y-0008Mr-HL for forces-archive@megatron.ietf.org; Fri, 28 Oct 2005 23:04:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05282 for ; Fri, 28 Oct 2005 23:03:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVhEb-0005Hz-Eo for forces-archive@IETF.ORG; Fri, 28 Oct 2005 23:18:25 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.01122B8B@cherry.ease.lsoft.com>; Fri, 28 Oct 2005 23:04:11 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89320226 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 28 Oct 2005 23:04:09 -0400 Received: from 207.69.195.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 28 Oct 2005 23:04:09 -0400 Received: from user-2ivepp7.dialup.mindspring.com ([165.247.103.39] helo=JMHLap3.stevecrocker.com) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EVh0l-0005H2-00 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 28 Oct 2005 23:04:09 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E07348177@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051028230058.030ad748@localhost> Date: Fri, 28 Oct 2005 23:03:44 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E07348177@orsmsx408> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable My preference is for the DCCP option. Operating without congestion control at all would be a bad idea. Attempting to invent our own "simple" congestion control is a mistake. And while using TCP is attractive, the operation of nested control loops=20 (TCP application like BGP or telnet to console with TML TCP nested inside)= =20 is a notoriously error prone phenomena. The concern about a stable stack is clearly important. if there are=20 indications that there are stable DCCP implementations, that would make the= =20 choice pretty clear for me. Yours, Joel At 02:05 AM 10/28/2005, Khosravi, Hormuzd M wrote: >Hi Folks, > >I would like to know what thoughts the WG has on the data channel=20 >transport for the TCP/IP TML that is the default ForCES TML. >This is the main issue remaining before we can take this draft to WG LC. > >There are couple of options available for the data channel transport= protocol: > >TCP =96 This would work well with the TCP connection that is used for the= =20 >control channel. However, there are issues around behavior with routing=20 >protocols such as BGP that themselves use TCP. > >DCCP =96 This is the best theoretical option in terms of the properties it= =20 >possesses, i.e. no-reliable transport protocol with Congestion Control=20 >(CC). The only issue with this in the past has bee lack of stable=20 >implementations. But this was over a year back when I was doing some=20 >experiments, I have been told that this is no longer the case. > >UDP with some sort of rate limiting or CC =96 This option would essentially= =20 >be reinventing the wheel in terms of what has been done with DCCP to some= =20 >extent, unless we can find a straight forward way to do this. Also,=20 >co-existence with TCP CC mechanism used by control channel is unknown. > >I would like to hear from the WG at this point. If we can reach a rough=20 >consensus soon, that would be great. > > >Thanks >Hormuzd > From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 28 23:40:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVhaE-00066n-Ut for forces-archive@megatron.ietf.org; Fri, 28 Oct 2005 23:40:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06570 for ; Fri, 28 Oct 2005 23:40:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVhnn-0005zc-Al for forces-archive@IETF.ORG; Fri, 28 Oct 2005 23:54:51 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.01122E31@cherry.ease.lsoft.com>; Fri, 28 Oct 2005 23:40:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89322433 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 28 Oct 2005 23:40:31 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 28 Oct 2005 23:40:30 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Sat, 29 Oct 2005 12:24:10 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sat, 29 Oct 2005 11:39:35 +0800 References: <468F3FDA28AA87429AD807992E22D07E07348177@orsmsx408> <6.2.1.2.0.20051028230058.030ad748@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <006b01c5dc3a$2f4a2790$1152010a@Necom.hzic.edu.cn> Date: Sat, 29 Oct 2005 11:38:10 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d A general comment is, after an experience with the ForCES implementation, I strongly believe the TCP+ UDP would be the best and fundamental choice ForCES users for their implementations, thought I think the TCP+DCCP may not be excluded totally from customs who are more pioneer. Note that UDP congestion has already been existing, while Internet is also still running quite efficiently. I don't think DCCP will act as the liberator for this issue. Focusing on UDP and resloving the congestion at specific application cases is still the basic way for current Internet applications. Joel, also more comments inline of your text. Thanks. regards, Weiming ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: TML data channel transport protocol choice? My preference is for the DCCP option. Operating without congestion control at all would be a bad idea. [W] Agreed. Attempting to invent our own "simple" congestion control is a mistake. [W] Really? Why is it a mistake? If it is a simple and efficient way, why not choose it? And while using TCP is attractive, the operation of nested control loops (TCP application like BGP or telnet to console with TML TCP nested inside) is a notoriously error prone phenomena. The concern about a stable stack is clearly important. if there are indications that there are stable DCCP implementations, that would make the choice pretty clear for me. [W] A simple DCCP implementation is not enough, I think. For things like our ForCES case, at least, we should evaluate how it acts together with TCP also. Yours, Joel At 02:05 AM 10/28/2005, Khosravi, Hormuzd M wrote: >Hi Folks, > >I would like to know what thoughts the WG has on the data channel >transport for the TCP/IP TML that is the default ForCES TML. >This is the main issue remaining before we can take this draft to WG LC. > >There are couple of options available for the data channel transport protocol: > >TCP - This would work well with the TCP connection that is used for the >control channel. However, there are issues around behavior with routing >protocols such as BGP that themselves use TCP. > >DCCP - This is the best theoretical option in terms of the properties it >possesses, i.e. no-reliable transport protocol with Congestion Control >(CC). The only issue with this in the past has bee lack of stable >implementations. But this was over a year back when I was doing some >experiments, I have been told that this is no longer the case. > >UDP with some sort of rate limiting or CC - This option would essentially >be reinventing the wheel in terms of what has been done with DCCP to some >extent, unless we can find a straight forward way to do this. Also, >co-existence with TCP CC mechanism used by control channel is unknown. > >I would like to hear from the WG at this point. If we can reach a rough >consensus soon, that would be great. > > >Thanks >Hormuzd > From HelenWu@xtremejaialai.com Sat Oct 29 00:51:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVigI-0000Hc-FD for forces-archive@megatron.ietf.org; Sat, 29 Oct 2005 00:51:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10632 for ; Sat, 29 Oct 2005 00:50:42 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVito-0007on-Rb for forces-archive@ietf.org; Sat, 29 Oct 2005 01:05:10 -0400 Received: from [62.117.169.96] (helo=96.red-62-117-169.user.auna.net) by mx2.foretec.com with smtp (Exim 4.24) id 1EVig0-0008Q7-73 for forces-archive@ietf.org; Sat, 29 Oct 2005 00:50:45 -0400 Received: from B7u@localhost by IG5.int (8.11.6/8.11.6); Sat, 29 Oct 2005 11:58:35 +0600 Message-ID: <85J9KtjEhSEQwvZX296FVnYO@ynthveg.com> From: "Vivian Nguyen" Reply-To: "Vivian Nguyen" To: forces-archive@ietf.org Subject: Systemworks & Macromedia Software Starting at $29 Date: Sat, 29 Oct 2005 02:02:35 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: HelenWu@xtremejaialai.com Content-Type: multipart/mixed; boundary="--cqHvDsJGQRR41nQduO" X-Spam-Score: 3.6 (+++) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Xhn5 ----cqHvDsJGQRR41nQduO Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 7
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

Microsoft Window= s XP Professional *w/SP2*
Microsoft

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

=
=  <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
 = ;2 Creative Suite 2
 3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 <= /td>5 Macromedia Flash 8
 = 6 Dreamweaver 8
 7= Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 = ;10 Borland Architect 2005
&= nbsp; See more by this manufacturer
   Microsoft
   Macromedia
  Ado= be
  Customers also b= ought
   these other items...

<= /p>

Choose:<= /b>
=  <= input type=3Dimage alt=3DGo src=3Dhttp://g-images.amazon.com/images/G/01/s= earch-browse/go-button-software.gif value=3DGo border=3D0 name=3Dsubmit.di= splay-variation width=3D21 height=3D21>
<= /tr>
List Price:$299.00
Price:$49.99
Y= ou Save:$249.01 (80%)


Availability: Available for INSTANT download= !
Coupon Code: 2VOedLAo
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date Co= upon Expires: December 31st, 2005
Ave= rage Customer Review:3D"5 Based on 148541 reviews. Write a review.

<= tr>

Adobe Creative Suite 2 = *Premium*
Ad= obe

Choose:<= tr>
 

List Price:<= /b>$1199.00
Price:$149.99
You Save:$1049.01 (95%)


Availability: Available for INSTANT download!
Coupon Code= : v9M7lD
Platform: Windows XP

Sales Rank:= #2
Syste= m requirements  |  Other V= ersions
Date Coupon Expires: Dece= mber 31st, 2005
Average Customer Review:<= /b>3D"5 Based on 1956 reviews. Write= a review.

Microsoft Office 2003 *Professio= nal*
Microso= ft

Choose:<= tr>
 

You Save:



Availability: Available for INSTANT downl= oad!
Coupon Code: QpakYUXjH
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Dat= e Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 115686 reviews. Write a review.

=
List Price:$499.00
Price:$69.99
$429.01 (85%)

Adob= e Acrobat Professional V 7.0
Adobe=

Choose:
=  
List= Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (85%)

=

Availability: Available for INSTANT download!
Coupo= n Code: 68IfTjf
Platform: Windows XP

Sales Ra= nk: #4 System requirements  |  = Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer R= eview:3D"5 Based on 1653 reviews. Write a review.

----cqHvDsJGQRR41nQduO-- From owner-forces@PEACH.EASE.LSOFT.COM Sat Oct 29 08:47:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVq7N-00031p-Bb for forces-archive@megatron.ietf.org; Sat, 29 Oct 2005 08:47:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29128 for ; Sat, 29 Oct 2005 08:47:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVqL8-0002Lw-Gv for forces-archive@IETF.ORG; Sat, 29 Oct 2005 09:01:43 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.011234AD@cherry.ease.lsoft.com>; Sat, 29 Oct 2005 8:47:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89363756 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 29 Oct 2005 08:47:19 -0400 Received: from 207.69.195.63 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 29 Oct 2005 08:47:19 -0400 Received: from user-2ivf94k.dsl.mindspring.com ([165.247.164.148] helo=JMHLap3.stevecrocker.com) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EVq7D-0002om-00 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 29 Oct 2005 08:47:19 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E07348177@orsmsx408> <6.2.1.2.0.20051028230058.030ad748@localhost> <006b01c5dc3a$2f4a2790$1152010a@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051029084218.030b0f70@localhost> Date: Sat, 29 Oct 2005 08:47:17 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <006b01c5dc3a$2f4a2790$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 UDP has no congestion control. The IETF as a whole has realized that standardizing protocols without congestion control is a bad idea. Following the example of our approach to security, there needs to be a mandatory-to-implement mechanism with congestion control. There may be other optional mechanisms (raw backplane usage, etc.) for special circumstances. The problem is that the folks who need to be handed congestion control are not the really sharp users who know what they are doing, but the relatively naive users who stretch the envelop of where the tool they have been handed should be used. With regard to inventing out own, congestion handling (detection, response, & control) is quite tricky. Very sharp people have gotten in wrong before. The assumption that ~this is an easy case, this simple mechanism will work~ often turns out very badly. If DCCP is not stable, there may be an argument that we need to invent a solution. But in the presence of a verified and usable solution from another IETF working group, there is no good reason to invent our own congestion response.. Yours, Joel M. Halpern At 11:38 PM 10/28/2005, Wang,Weiming wrote: >A general comment is, after an experience with the ForCES implementation, I >strongly believe the TCP+ UDP would be the best and fundamental choice ForCES >users for their implementations, thought I think the TCP+DCCP may not be >excluded totally from customs who are more pioneer. > >Note that UDP congestion has already been existing, while Internet is also >still >running quite efficiently. I don't think DCCP will act as the liberator >for this >issue. Focusing on UDP and resloving the congestion at specific application >cases is still the basic way for current Internet applications. > >Joel, also more comments inline of your text. Thanks. > >regards, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >Subject: Re: TML data channel transport protocol choice? > > >My preference is for the DCCP option. > >Operating without congestion control at all would be a bad idea. > >[W] Agreed. > >Attempting to invent our own "simple" congestion control is a mistake. > >[W] Really? Why is it a mistake? If it is a simple and efficient way, >why not >choose it? From owner-forces@PEACH.EASE.LSOFT.COM Sat Oct 29 11:18:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVsTM-0001FX-1a for forces-archive@megatron.ietf.org; Sat, 29 Oct 2005 11:18:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06204 for ; Sat, 29 Oct 2005 11:18:01 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVsh9-00061K-GR for forces-archive@IETF.ORG; Sat, 29 Oct 2005 11:32:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0112348F@cherry.ease.lsoft.com>; Sat, 29 Oct 2005 11:18:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89375152 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 29 Oct 2005 11:18:17 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 29 Oct 2005 11:18:16 -0400 Received: from [58.100.182.141] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Sun, 30 Oct 2005 00:02:00 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E07348177@orsmsx408> <6.2.1.2.0.20051028230058.030ad748@localhost> <006b01c5dc3a$2f4a2790$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20051029084218.030b0f70@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <010a01c5dc9b$ee50ee10$fefefe0a@wwm1> Date: Sat, 29 Oct 2005 23:17:35 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 ----- Original Message ----- From: "Joel M. Halpern" > UDP has no congestion control. The IETF as a whole has realized that > standardizing protocols without congestion control is a bad idea. Raw data transport is generically hard for congestion control. That explains why after tens of years we have only a thing like DCCP, and why IETF could not find a better substitute for UDP in so long a period. This actually also means UPD has been the best choice rather than a bad idea in terms of the solutions available. > Following the example of our approach to security, there needs to be a > mandatory-to-implement mechanism with congestion control. There may be I should note that the ForCES does not and also does not need to mandatory precise and strict congestion control on redirect data transmission, the ForCES does mandatory it on PL control messages. The only requirement mandatory to redirect data transport is it must not block control message transmission, therefore putting a complex and complete CC on it MAYBE a luxury. > other optional mechanisms (raw backplane usage, etc.) for special > circumstances. > > The problem is that the folks who need to be handed congestion control are > not the really sharp users who know what they are doing, but the relatively > naive users who stretch the envelop of where the tool they have been handed > should be used. > > With regard to inventing out own, congestion handling (detection, response, > & control) is quite tricky. Very sharp people have gotten in wrong Joel, I can understand your worry here, but as mentioned above, the ForCES may not have to face a very strict CC problem, or in other words, the issue we now face, as I can see, is only the DoS prevention problem, just like that in many other Internet applications. > before. The assumption that ~this is an easy case, this simple mechanism > will work~ often turns out very badly. If DCCP is not stable, there may be > an argument that we need to invent a solution. But in the presence of a I'm not very objective to DCCP deployed for ForCES, but as you being an experienced expert in IETF may know well, a transport layer IETF protocol acting as the fundamentals for Internet, may need to take a very long time before it can be evaluated. UDP has been in place for tens of years while we still evaluate it. I just worry it may be too early we now too highly rely on a standard track TRANSPORT PROTOCOL that has just got approved as RFC. I also a little worry that DCCP as a newer to us, it may in one place slow down the ForCES progress, and in another place it may also has negative side effect for ForCES applications. Whereas, I'm not in the same page that we take DCCP into acount and may choose it as an alternative TML, and to develop such TML in a pace just along with the DCCP progress. Thanks, Weiming > verified and usable solution from another IETF working group, there is no > good reason to invent our own congestion response.. > > Yours, > Joel M. Halpern > > At 11:38 PM 10/28/2005, Wang,Weiming wrote: > >A general comment is, after an experience with the ForCES implementation, I > >strongly believe the TCP+ UDP would be the best and fundamental choice ForCES > >users for their implementations, thought I think the TCP+DCCP may not be > >excluded totally from customs who are more pioneer. > > > >Note that UDP congestion has already been existing, while Internet is also > >still > >running quite efficiently. I don't think DCCP will act as the liberator > >for this > >issue. Focusing on UDP and resloving the congestion at specific application > >cases is still the basic way for current Internet applications. > > > >Joel, also more comments inline of your text. Thanks. > > > >regards, > >Weiming > > > >----- Original Message ----- > >From: "Joel M. Halpern" > >Subject: Re: TML data channel transport protocol choice? > > > > > >My preference is for the DCCP option. > > > >Operating without congestion control at all would be a bad idea. > > > >[W] Agreed. > > > >Attempting to invent our own "simple" congestion control is a mistake. > > > >[W] Really? Why is it a mistake? If it is a simple and efficient way, > >why not > >choose it? From owner-forces@PEACH.EASE.LSOFT.COM Sat Oct 29 17:37:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVyNw-0003N2-EP for forces-archive@megatron.ietf.org; Sat, 29 Oct 2005 17:37:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26252 for ; Sat, 29 Oct 2005 17:36:49 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVybm-0008PG-CK for forces-archive@IETF.ORG; Sat, 29 Oct 2005 17:51:27 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.01123766@cherry.ease.lsoft.com>; Sat, 29 Oct 2005 17:37:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89399184 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 29 Oct 2005 17:37:01 -0400 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 29 Oct 2005 17:37:01 -0400 Received: from user-2ivepqa.dialup.mindspring.com ([165.247.103.74] helo=JMHLap3.stevecrocker.com) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EVyNh-0005vH-00 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 29 Oct 2005 17:36:57 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051029173615.0328d6f0@localhost> Date: Sat, 29 Oct 2005 17:36:28 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 I don't agree. Consider that the IETF is pushing all protocols to consider congestion issues where they ignored them before. I was talking with Scott Bradner. He sponsored the original BoF for ForCES. He sponsored the BoF in the transport area. The reason he sponsored the BofF is that he considered (and still considers) it important that we deal with congestion control in all aspects of our work. I have no objection in principle to alternative TMLs without congestion control. (For some, such an omission is probably quite reasonable.) But we have to have a mandatory to implement TML that works across a range of cases. Thus, I would like to see DCCP used for the redirect channel for that TML. Yours, Joel M. Halpern At 11:17 AM 10/29/2005, Weiming Wang wrote: >I should note that the ForCES does not and also does not need to mandatory >precise and strict congestion control on redirect data transmission, the >ForCES >does mandatory it on PL control messages. The only requirement mandatory to >redirect data transport is it must not block control message transmission, >therefore putting a complex and complete CC on it MAYBE a luxury. From owner-forces@PEACH.EASE.LSOFT.COM Sat Oct 29 21:43:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW2EW-0001kB-CK for forces-archive@megatron.ietf.org; Sat, 29 Oct 2005 21:43:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05346 for ; Sat, 29 Oct 2005 21:43:21 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EW2SO-0005KO-4z for forces-archive@IETF.ORG; Sat, 29 Oct 2005 21:58:01 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.01123991@cherry.ease.lsoft.com>; Sat, 29 Oct 2005 21:43:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89413106 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 29 Oct 2005 21:43:36 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 29 Oct 2005 21:43:35 -0400 Received: from [219.82.185.120] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Sun, 30 Oct 2005 10:27:27 +0800 (CST) References: <6.2.1.2.0.20051029173615.0328d6f0@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <002001c5dcf3$4acc6500$fefefe0a@wwm1> Date: Sun, 30 Oct 2005 09:43:11 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Using DCCP in our case and appling it to the case like TCPoverDCCP also has the potential to lead to the problem like TCPoverTCP. Note that the generic cause for the extreme low efficiency of TCPoverTCP is the CongestionControl-Over-CongestionControl algirithm. By checking the congestioncontrol method DCCP applies which is generally quite identical to TCP only regarding the congestion control aspects, I have no feeling that the same problem can be avoided compared with TCPoverTCP. Thanks, Weiming ----- Original Message ----- From: "Joel M. Halpern" > I don't agree. > Consider that the IETF is pushing all protocols to consider congestion > issues where they ignored them before. > I was talking with Scott Bradner. He sponsored the original BoF for > ForCES. He sponsored the BoF in the transport area. The reason he > sponsored the BofF is that he considered (and still considers) it important > that we deal with congestion control in all aspects of our work. > > I have no objection in principle to alternative TMLs without congestion > control. (For some, such an omission is probably quite reasonable.) > But we have to have a mandatory to implement TML that works across a range > of cases. > Thus, I would like to see DCCP used for the redirect channel for that TML. > > Yours, > Joel M. Halpern > > At 11:17 AM 10/29/2005, Weiming Wang wrote: > >I should note that the ForCES does not and also does not need to mandatory > >precise and strict congestion control on redirect data transmission, the > >ForCES > >does mandatory it on PL control messages. The only requirement mandatory to > >redirect data transport is it must not block control message transmission, > >therefore putting a complex and complete CC on it MAYBE a luxury. From owner-forces@PEACH.EASE.LSOFT.COM Sat Oct 29 21:51:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW2MA-0003sK-Hn for forces-archive@megatron.ietf.org; Sat, 29 Oct 2005 21:51:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05683 for ; Sat, 29 Oct 2005 21:51:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EW2a1-0005X7-KH for forces-archive@IETF.ORG; Sat, 29 Oct 2005 22:05:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0112393A@cherry.ease.lsoft.com>; Sat, 29 Oct 2005 21:51:31 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89413376 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 29 Oct 2005 21:51:29 -0400 Received: from 207.69.195.65 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 29 Oct 2005 21:51:29 -0400 Received: from user-2ivf96p.dsl.mindspring.com ([165.247.164.217] helo=JMHLap3.stevecrocker.com) by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EW2M4-0003ps-00 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 29 Oct 2005 21:51:29 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051029215117.032afc18@localhost> Date: Sat, 29 Oct 2005 21:51:26 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 With DCCP, we could choose a behavior that provides discard rather than pacing.DCCP does not perform retransmission. A home-brew rate control would have significant risk of interacting with TCP timers. Yes, there is probably some risk of negative interaction of TCP applications and DCCP behaviors. But any congested link produces some negaitve effects. The point is to use something with reasonably low risk of problem. Yours, Joel At 10:43 PM 10/29/2005, Weiming Wang wrote: >Using DCCP in our case and appling it to the case like TCPoverDCCP also >has the >potential to lead to the problem like TCPoverTCP. Note that the generic cause >for the extreme low efficiency of TCPoverTCP is the >CongestionControl-Over-CongestionControl algirithm. By checking the >congestioncontrol method DCCP applies which is generally quite identical >to TCP >only regarding the congestion control aspects, I have no feeling that the same >problem can be avoided compared with TCPoverTCP. > >Thanks, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" > > > I don't agree. > > Consider that the IETF is pushing all protocols to consider congestion > > issues where they ignored them before. > > I was talking with Scott Bradner. He sponsored the original BoF for > > ForCES. He sponsored the BoF in the transport area. The reason he > > sponsored the BofF is that he considered (and still considers) it important > > that we deal with congestion control in all aspects of our work. > > > > I have no objection in principle to alternative TMLs without congestion > > control. (For some, such an omission is probably quite reasonable.) > > But we have to have a mandatory to implement TML that works across a range > > of cases. > > Thus, I would like to see DCCP used for the redirect channel for that TML. > > > > Yours, > > Joel M. Halpern > > > > At 11:17 AM 10/29/2005, Weiming Wang wrote: > > >I should note that the ForCES does not and also does not need to mandatory > > >precise and strict congestion control on redirect data transmission, the > > >ForCES > > >does mandatory it on PL control messages. The only requirement > mandatory to > > >redirect data transport is it must not block control message transmission, > > >therefore putting a complex and complete CC on it MAYBE a luxury. From owner-forces@PEACH.EASE.LSOFT.COM Sat Oct 29 23:03:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW3U9-0007wt-9x for forces-archive@megatron.ietf.org; Sat, 29 Oct 2005 23:03:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07845 for ; Sat, 29 Oct 2005 23:03:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EW3i2-00070e-GW for forces-archive@IETF.ORG; Sat, 29 Oct 2005 23:18:15 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.01123B24@cherry.ease.lsoft.com>; Sat, 29 Oct 2005 23:03:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89417538 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 29 Oct 2005 23:00:53 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 29 Oct 2005 23:00:30 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Sun, 30 Oct 2005 11:44:23 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sun, 30 Oct 2005 10:59:36 +0800 References: <6.2.1.2.0.20051029173615.0328d6f0@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <004d01c5dcfd$c2e23b50$1152010a@Necom.hzic.edu.cn> Date: Sun, 30 Oct 2005 10:58:10 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ----- Original Message ----- From: "Joel M. Halpern" > I don't agree. > Consider that the IETF is pushing all protocols to consider congestion > issues where they ignored them before. > I was talking with Scott Bradner. He sponsored the original BoF for > ForCES. He sponsored the BoF in the transport area. The reason he > sponsored the BofF is that he considered (and still considers) it important > that we deal with congestion control in all aspects of our work. For PL control messages that originate and also destinate in one ForCES NE, I have no doubt on this desire, but for redirect data, for which FE only acts as one of the intermediate nodes, by which trasport may be across wide range of networks, I don't see any value and extreme desire( except for DoS prevention) to apply full CC for only such one node, while other nodes out of the FoCES NE are still not CC mandatory. > > I have no objection in principle to alternative TMLs without congestion > control. (For some, such an omission is probably quite reasonable.) > But we have to have a mandatory to implement TML that works across a range > of cases. I'm not sure how we can have a mandatory one while we still have an alternative one? My simplest thought is we should have a basic one like TCP+UDP TML to provide common users with an IP TML solution, then we can have a TCP+DCCP TML for users who like to be more advanced after we have had DCCP quite evaluated. > Thus, I would like to see DCCP used for the redirect channel for that TML. I'd like to see this after more evaluation of the brand new protocol. Thanks, Weiming > > Yours, > Joel M. Halpern > > At 11:17 AM 10/29/2005, Weiming Wang wrote: > >I should note that the ForCES does not and also does not need to mandatory > >precise and strict congestion control on redirect data transmission, the > >ForCES > >does mandatory it on PL control messages. The only requirement mandatory to > >redirect data transport is it must not block control message transmission, > >therefore putting a complex and complete CC on it MAYBE a luxury. From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 30 00:14:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW4a9-0003J7-7M for forces-archive@megatron.ietf.org; Sun, 30 Oct 2005 00:14:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11837 for ; Sun, 30 Oct 2005 00:13:51 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EW4nw-0000gZ-Lk for forces-archive@IETF.ORG; Sun, 30 Oct 2005 00:28:31 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.01123E48@cherry.ease.lsoft.com>; 30 Oct 2005 0:13:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89422309 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Oct 2005 00:13:21 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 30 Oct 2005 00:08:30 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Sun, 30 Oct 2005 12:52:20 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sun, 30 Oct 2005 12:07:31 +0800 References: <6.2.1.2.0.20051029215117.032afc18@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <005701c5dd07$403398c0$1152010a@Necom.hzic.edu.cn> Date: Sun, 30 Oct 2005 12:06:05 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 2.9 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Some more comments as below. One more thing for DCCP is, we are also very unclear how DCCP will act along with parallel TCP. This is the key point for avoiding DoS attack in the ForCES case. Because DCCP does not retransmit packets, I have a prediect that DCCP will still act more agressively than TCP. As a result, purely adopting DCCP actually does not prevent DoS then. This means if we adot it, we still have to find other mechanism to avoid DoS, which leads to the same way as we face when we have initially adopted UDP. Thanks, Weiming ----- Original Message ----- From: "Joel M. Halpern" > With DCCP, we could choose a behavior that provides discard rather than > pacing.DCCP does not perform retransmission. > A home-brew rate control would have significant risk of interacting with > TCP timers. Sub-section double ACKs, sub-section retransmission, and sub-section windowing that does not match whole section TCP windowing, all of these contribute to TCP inefficiency. DCCP only avoid the retransmission among these. DCCP still adopts AIMD, which obviously negatively interacts with the above TCP AIMD. > > Yes, there is probably some risk of negative interaction of TCP > applications and DCCP behaviors. But any congested link produces some > negaitve effects. The point is to use something with reasonably low risk > of problem. I agree with this, therefore I tend to the method that we adopt CC only moderately and especially in our case only when DoS attack happens. For normal state, we just keep the transmission as raw as possible. > > Yours, > Joel > > At 10:43 PM 10/29/2005, Weiming Wang wrote: > >Using DCCP in our case and appling it to the case like TCPoverDCCP also > >has the > >potential to lead to the problem like TCPoverTCP. Note that the generic cause > >for the extreme low efficiency of TCPoverTCP is the > >CongestionControl-Over-CongestionControl algirithm. By checking the > >congestioncontrol method DCCP applies which is generally quite identical > >to TCP > >only regarding the congestion control aspects, I have no feeling that the same > >problem can be avoided compared with TCPoverTCP. > > > >Thanks, > >Weiming > > > >----- Original Message ----- > >From: "Joel M. Halpern" > > > > > I don't agree. > > > Consider that the IETF is pushing all protocols to consider congestion > > > issues where they ignored them before. > > > I was talking with Scott Bradner. He sponsored the original BoF for > > > ForCES. He sponsored the BoF in the transport area. The reason he > > > sponsored the BofF is that he considered (and still considers) it important > > > that we deal with congestion control in all aspects of our work. > > > > > > I have no objection in principle to alternative TMLs without congestion > > > control. (For some, such an omission is probably quite reasonable.) > > > But we have to have a mandatory to implement TML that works across a range > > > of cases. > > > Thus, I would like to see DCCP used for the redirect channel for that TML. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 11:17 AM 10/29/2005, Weiming Wang wrote: > > > >I should note that the ForCES does not and also does not need to mandatory > > > >precise and strict congestion control on redirect data transmission, the > > > >ForCES > > > >does mandatory it on PL control messages. The only requirement > > mandatory to > > > >redirect data transport is it must not block control message transmission, > > > >therefore putting a complex and complete CC on it MAYBE a luxury. From maria_ralph@domainsware.com Sun Oct 30 14:24:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWImf-0006A9-Jp for forces-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:24:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08594 for ; Sun, 30 Oct 2005 14:23:41 -0500 (EST) Received: from [84.20.228.112] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWF5C-0005tU-0n for forces-archive@ietf.org; Sun, 30 Oct 2005 10:26:57 -0500 Message-ID: <000001c5dd63$bb12cf00$0100007f@localhost> From: "Thomas Richardson" To: Subject: Buy OEM Software Date: Sun, 30 Oct 2005 15:12:17 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5DD63.BB12CF00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5DD63.BB12CF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TOP 10 NEW TITLES ON SALE NOW! 1 Office Pro 2003 2 Adobe Photoshop 9.0 3 Windows XP Pro 4 Adobe Acrobat 7 Pro 5 Flash MX 2004 6 Corel Draw 12 7 Norton Antivirus 2005 8 Windows 2003 Server 9 Alias Maya 6 Wavefrt 10 Adobe Illustrator 11 See more by this manufacturer Microsoft Symantec Adobe Microsoft Office Professional Edition 2003 by Microsoft ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- http://liberationsoft.net/ ------=_NextPart_000_0001_01C5DD63.BB12CF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 38 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 45 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 41 reviews)

------=_NextPart_000_0001_01C5DD63.BB12CF00-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 30 14:31:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIst-0000eF-W1 for forces-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:30:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09995 for ; Sun, 30 Oct 2005 14:25:38 -0500 (EST) Received: from almond.ease.lsoft.com ([209.119.0.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWE7D-0005Qi-4e for forces-archive@IETF.ORG; Sun, 30 Oct 2005 09:24:56 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.0096FA6D@almond.ease.lsoft.com>; 30 Oct 2005 9:10:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89459036 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Oct 2005 09:10:26 -0500 Received: from 207.69.195.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 30 Oct 2005 09:10:26 -0400 Received: from user-2ivf964.dsl.mindspring.com ([165.247.164.196] helo=JMHLap3.stevecrocker.com) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EWDtB-0007Cm-00 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Oct 2005 09:10:26 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20051029215117.032afc18@localhost> <005701c5dd07$403398c0$1152010a@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051030090920.030bb4f0@localhost> Date: Sun, 30 Oct 2005 09:10:23 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <005701c5dd07$403398c0$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On of the key reasons DCCP was developed is that its behavior is designed to work well with TCP> Without care, the exact problem you describe will occur. Yours, Joel M. Halpern At 12:06 AM 10/30/2005, Wang,Weiming wrote: >Some more comments as below. > >One more thing for DCCP is, we are also very unclear how DCCP will act along >with parallel TCP. This is the key point for avoiding DoS attack in the >ForCES >case. Because DCCP does not retransmit packets, I have a prediect that >DCCP will >still act more agressively than TCP. As a result, purely adopting DCCP >actually >does not prevent DoS then. This means if we adot it, we still have to find >other mechanism to avoid DoS, which leads to the same way as we face when we >have initially adopted UDP. > >Thanks, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 30 14:32:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIs2-0000Fs-7X for forces-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:29:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04584 for ; Sun, 30 Oct 2005 14:18:28 -0500 (EST) Received: from almond.ease.lsoft.com ([209.119.0.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWI0W-0003og-D6 for forces-archive@IETF.ORG; Sun, 30 Oct 2005 13:34:20 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.00972301@almond.ease.lsoft.com>; 30 Oct 2005 13:19:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89477889 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Oct 2005 13:19:44 -0500 Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 30 Oct 2005 13:19:43 -0400 Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.54) id 1EWHmQ-00071J-0o for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Oct 2005 18:19:43 +0000 Received: from s182-3.nomadic.bris.ac.uk ([137.222.182.3] helo=een5134.een.bris.ac.uk) by isis.bris.ac.uk with esmtp (Exim 4.54) id 1EWHkW-0005dh-M7 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Oct 2005 18:17:47 +0000 References: <6.2.1.2.0.20051029215117.032afc18@localhost> <005701c5dd07$403398c0$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20051030090920.030bb4f0@localhost> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.4 X-Spam-Level: - Approved-By: Alistair Munro Message-ID: <52B1C7ED8FA796C0C8221C28@[192.168.0.2]> Date: Sun, 30 Oct 2005 18:17:44 +0000 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20051030090920.030bb4f0@localhost> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Hi All, > On of the key reasons DCCP was developed is that its behavior is designed > to work well with TCP> > Without care, the exact problem you describe will occur. As far as I can tell, DCCP does fit the requirements but implementations are experimental. Probably more experience is needed before DCCP can be recommended - however, it should not be ruled out. What about SCTP? Or did that get excluded already? Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 30 14:34:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIsu-0000eF-3x for forces-archive@megatron.ietf.org; Sun, 30 Oct 2005 14:30:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10027 for ; Sun, 30 Oct 2005 14:25:40 -0500 (EST) Received: from almond.ease.lsoft.com ([209.119.0.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWE4h-0004or-UH for forces-archive@IETF.ORG; Sun, 30 Oct 2005 09:22:24 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.0096FEA2@almond.ease.lsoft.com>; 30 Oct 2005 9:07:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89458924 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Oct 2005 09:07:44 -0500 Received: from 207.69.195.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 30 Oct 2005 09:07:44 -0400 Received: from user-2ivf964.dsl.mindspring.com ([165.247.164.196] helo=JMHLap3.stevecrocker.com) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EWDqa-0006kc-00 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Oct 2005 09:07:44 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20051029173615.0328d6f0@localhost> <004d01c5dcfd$c2e23b50$1152010a@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051030090455.030e7e20@localhost> Date: Sun, 30 Oct 2005 09:07:41 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <004d01c5dcfd$c2e23b50$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 In order to enable interoperability, there needs to be a TML that every ForCES implementation supports. There can be other stacks in the implementaiton as well. Local configuration will determine which stack is used if there are multiple choices in the implementaiton. Without a "mandatory to implement" mechanism, two independent implementations do not have a mechanism that can be counted on to communicate. This approach to the handling of optional mechanisms has been used by the IETF on many occaisons. It is, for example, how we handle security. Yours, Joel M. Halpern At 10:58 PM 10/29/2005, Wang,Weiming wrote: >I'm not sure how we can have a mandatory one while we still have an >alternative >one? My simplest thought is we should have a basic one like TCP+UDP TML to >provide common users with an IP TML solution, then we can have a TCP+DCCP TML >for users who like to be more advanced after we have had DCCP quite evaluated. From owner-forces@PEACH.EASE.LSOFT.COM Sun Oct 30 16:37:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWKrf-0008Ac-QS for forces-archive@megatron.ietf.org; Sun, 30 Oct 2005 16:37:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19610 for ; Sun, 30 Oct 2005 16:37:00 -0500 (EST) Received: from almond.ease.lsoft.com ([209.119.0.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWL5i-0002DY-CQ for forces-archive@IETF.ORG; Sun, 30 Oct 2005 16:51:51 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00971443@almond.ease.lsoft.com>; 30 Oct 2005 16:37:17 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89488767 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Oct 2005 16:37:16 -0500 Received: from 207.69.195.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 30 Oct 2005 16:37:16 -0400 Received: from user-2ivf96d.dsl.mindspring.com ([165.247.164.205] helo=JMHLap3.stevecrocker.com) by pop-gadwall.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EWKrc-0002Qp-00 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Oct 2005 16:37:16 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20051029215117.032afc18@localhost> <005701c5dd07$403398c0$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20051030090920.030bb4f0@localhost> <52B1C7ED8FA796C0C8221C28@[192.168.0.2]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051030163512.031573b8@localhost> Date: Sun, 30 Oct 2005 16:37:13 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52B1C7ED8FA796C0C8221C28@[192.168.0.2]> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Is there an SCTP mode without retransmission? I had understood SCTP to always offer reliable service. And the redirect channel does not need reliability. I know that they have put more capabilities in SCTP than I had understood in other ways, so it is possible there is a suitable branch here. I have been informed that the state of DCCP implementations has gotten better. And it is a standards track protocol. Yours, Joel M. Halpern At 01:17 PM 10/30/2005, Alistair Munro wrote: >Hi All, > >>On of the key reasons DCCP was developed is that its behavior is designed >>to work well with TCP> >>Without care, the exact problem you describe will occur. > >As far as I can tell, DCCP does fit the requirements but implementations >are experimental. Probably more experience is needed before DCCP can be >recommended - however, it should not be ruled out. > >What about SCTP? Or did that get excluded already? > >Regards, > >Alistair > >-- >Alistair Munro, >Principal Engineer, U4EA Technologies Ltd. >City Point, Temple Gate, Bristol, BS1 6PL, U.K. >E-mail: Alistair.Munro@u4eatech.com >Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) >+44-7974-922-442; >Fax: +44-117-373-6751 >Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 31 10:57:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc2P-000545-6P for forces-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:57:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15689 for ; Mon, 31 Oct 2005 10:57:13 -0500 (EST) Received: from almond.ease.lsoft.com ([209.119.0.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcGX-0001fj-Pz for forces-archive@IETF.ORG; Mon, 31 Oct 2005 11:12:14 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.009725E2@almond.ease.lsoft.com>; Mon, 31 Oct 2005 10:57:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89577877 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 31 Oct 2005 10:57:14 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 31 Oct 2005 10:57:13 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j9VFvBcC012692; Mon, 31 Oct 2005 15:57:11 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j9VFu03Z002705; Mon, 31 Oct 2005 15:57:11 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005103107571030611 ; Mon, 31 Oct 2005 07:57:11 -0800 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 07:57:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] TML data channel transport protocol choice? thread-index: AcXdmhr2bNPhZjxKQpSbxQaTDtR5OQAmP1iQ X-OriginalArrivalTime: 31 Oct 2005 15:57:10.0960 (UTC) FILETIME=[C0D1CB00:01C5DE33] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 Approved-By: "Putzolu, David" Message-ID: Date: Mon, 31 Oct 2005 07:57:07 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: TML data channel transport protocol choice? Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Hi Joel. Speaking for myself, I agree that we must not invent new protocols or applications that add congestion-clueless ness to the Internet. However, does the redirection side of ForCES qualify as a new protocol? As best I can tell, no ForCES-specific traffic is expected to be generated and sent over the redirection. Rather, all the traffic over the redirection side will be traffic that is would normally be sent/received over the Internet by regular routers, so the level of congestion-cluelessness on the Internet would not be changed if UDP where to be used in the ForCES TML. What do you think Joel? Is this splitting hairs? -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Sunday, October 30, 2005 1:37 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] TML data channel transport protocol choice? Is there an SCTP mode without retransmission? I had understood SCTP to=20 always offer reliable service. And the redirect channel does not need=20 reliability. I know that they have put more capabilities in SCTP than I had understood in other ways, so it is possible there is a suitable branch=20 here. I have been informed that the state of DCCP implementations has gotten=20 better. And it is a standards track protocol. Yours, Joel M. Halpern At 01:17 PM 10/30/2005, Alistair Munro wrote: >Hi All, > >>On of the key reasons DCCP was developed is that its behavior is designed >>to work well with TCP> >>Without care, the exact problem you describe will occur. > >As far as I can tell, DCCP does fit the requirements but implementations=20 >are experimental. Probably more experience is needed before DCCP can be >recommended - however, it should not be ruled out. > >What about SCTP? Or did that get excluded already? > >Regards, > >Alistair > >-- >Alistair Munro, >Principal Engineer, U4EA Technologies Ltd. >City Point, Temple Gate, Bristol, BS1 6PL, U.K. >E-mail: Alistair.Munro@u4eatech.com >Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) >+44-7974-922-442; >Fax: +44-117-373-6751 >Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 31 11:23:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcRy-0005o7-P6 for forces-archive@megatron.ietf.org; Mon, 31 Oct 2005 11:23:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18466 for ; Mon, 31 Oct 2005 11:23:38 -0500 (EST) Received: from almond.ease.lsoft.com ([209.119.0.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcg7-0005I4-JC for forces-archive@IETF.ORG; Mon, 31 Oct 2005 11:38:40 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.009737DF@almond.ease.lsoft.com>; Mon, 31 Oct 2005 11:21:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89583654 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 31 Oct 2005 11:21:05 -0500 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 31 Oct 2005 11:21:05 -0400 Received: from [12.58.128.11] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12691817 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 31 Oct 2005 09:20:05 -0700 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20051031111354.02d32060@localhost> Date: Mon, 31 Oct 2005 11:20:54 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: TML data channel transport protocol choice? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db It may be splitting hairs, but it is a hair I gave serious consideration to before expressing my opinion. I think it does strongly affect the basic reason that we need congestion control (or don't) on the redirect channel. If the network path the redirect packets were taking was (hypothetically) the same as the one that the packet would take anyway, then all we would be doing is putting an extra header on and sending the data packet. Tunnels do not require extra congestion control. However, the redirect packets are not taking that path. The redirect path has two properties that I believe drive the need for congestion control. Firstly, that redirect path is a funnel. Packets needing control attention (routing protocols, possibly ICMP, maybe others) from all the interfaces on the NE will be going over the redirect channel. While I would normally expect this to be a small set of traffic, under some circumstances it can be large. And it is much more concentrated than on any data link of the NE. (The traffic needing redirection is a small proportion of the traffic on each link, but can add up to quite a lot on the FE-CE link.) Secondly, the redirect path is shared with the reliable, flow controlled, ForCES control protocol. It is important that we make sure that overload of redirect traffic does not interfere with control operation. (After all, if it does interfere, then there is no way for the CE to make it stop interfering, because the CE can not communicate with the FE to change the FEs behavior.) So, I concluded that even though these redirect packets are normal IP packets, which can happily be discarded under stress / load, we need some congestion control on the redirect path. Yours, Joel At 10:57 AM 10/31/2005, Putzolu, David wrote: >Hi Joel. > >Speaking for myself, I agree that we must not invent new protocols or >applications that add congestion-clueless ness to the Internet. However, >does the redirection side of ForCES qualify as a new protocol? As best >I can tell, no ForCES-specific traffic is expected to be generated and >sent over the redirection. Rather, all the traffic over the redirection >side will be traffic that is would normally be sent/received over the >Internet by regular routers, so the level of congestion-cluelessness on >the Internet would not be changed if UDP where to be used in the ForCES >TML. > >What do you think Joel? Is this splitting hairs? > >-David > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Sunday, October 30, 2005 1:37 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] TML data channel transport protocol choice? > >Is there an SCTP mode without retransmission? I had understood SCTP to >always offer reliable service. And the redirect channel does not need >reliability. I know that they have put more capabilities in SCTP than I > >had understood in other ways, so it is possible there is a suitable >branch >here. > >I have been informed that the state of DCCP implementations has gotten >better. And it is a standards track protocol. > >Yours, >Joel M. Halpern > >At 01:17 PM 10/30/2005, Alistair Munro wrote: > >Hi All, > > > >>On of the key reasons DCCP was developed is that its behavior is >designed > >>to work well with TCP> > >>Without care, the exact problem you describe will occur. > > > >As far as I can tell, DCCP does fit the requirements but >implementations > >are experimental. Probably more experience is needed before DCCP can be > > >recommended - however, it should not be ruled out. > > > >What about SCTP? Or did that get excluded already? > > > >Regards, > > > >Alistair > > > >-- > >Alistair Munro, > >Principal Engineer, U4EA Technologies Ltd. > >City Point, Temple Gate, Bristol, BS1 6PL, U.K. > >E-mail: Alistair.Munro@u4eatech.com > >Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > >+44-7974-922-442; > >Fax: +44-117-373-6751 > >Web: http://www.u4eatech.com From robert@yahoo.com Mon Oct 31 16:53:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhaU-00049e-Pj for forces-archive@megatron.ietf.org; Mon, 31 Oct 2005 16:53:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13100 for ; Mon, 31 Oct 2005 16:52:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWhok-0001tX-WB for forces-archive@ietf.org; Mon, 31 Oct 2005 17:07:51 -0500 Received: from adsl-072-148-019-020.sip.bhm.bellsouth.net ([72.148.19.20] helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1EWhaT-0006Nt-PN for forces-archive@ietf.org; Mon, 31 Oct 2005 16:53:06 -0500 Date: Mon, 31 Oct 2005 15:53:16 +0100 From: "Gruber" To: Subject: Men's Health Message-ID: <001001c5dd93$bc191aa0$0200a8c0@noop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C5DD50.AC7AD360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.8 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5DD50.AC7AD360 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Suffering from pain, depression or heartburn? We'll help you! Great choice of wonderful meds to give you long-awaited relief!=20 Vlaggra as low as $3.84=20 ClaIis as low as $5.67=20 Xanaks as low as $2.47=20 VaIium as low as $3.41=20 Traumaddol as low as $3.30 UItram as low as $3.33=20 Soomma as low as $0.88=20 Meridida as low as $2.48=20 Our phartmacy is LICENSED, verified by BBB and approved by VISA!=20 ------=_NextPart_000_000D_01C5DD50.AC7AD360 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Suffering=20 from pain, depression or heartburn? We'll help=20 you!
Great=20 choice of wonderful meds to give you long-awaited relief!=20
 
Vlaggra=20 as low as $3.84 =
ClaIis=20 as low as $5.67 =
Xanaks=20 as low as $2.47 =
VaIium=20 as low as $3.41 =
Traumaddol=20 as low as=20 $3.30    
UItram=20 as low as $3.33 =
Soomma=20 as low as $0.88 =
Meridida=20 as low as $2.48 =
 
Our = phartmacy is=20 LICENSED, verified by BBB and approved by VISA!
 
------=_NextPart_000_000D_01C5DD50.AC7AD360--