2003 Message-Id: Date: Fri, 28 Mar 2003 18:52:29 -0500 From: Jon Maloy Subject: Re: XML experience/learning in FACT/TIPC implementation Comments: cc: "Rachid Nait Takourout (LMC)" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010906010409040903010908" --------------010906010409040903010908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by imr2.ericy.com id h2SNqdsB023830 I think the conclusion should be that we need to continue and widen the scope of our prototyping. We must also do some theoretical calculation on hwo much bandwidth=20 the use of XML will actually require, taking into account its ratio of of the total traffic load. If TIPC is chosen as bearer one should also consider that it is capable of=20 using 4 Ethernets in full load-sharing. With 10 Gbit Ethernet interfaces and switches there should be some potential.... Do anybody have an overview over the required frequency and distribution of=20 different types of commands/queries, both relative to each other an as a part=20 of the total? /Jon Alex Audu wrote: Also, don't forget other applications that may need a lot bandwidth between CEs and FEs, for example, traffic measurement. Typically you'd like your observers in the FEs to forward collected flow records to the Export process in the CE for aggregation and onward export to an external collector. I don't know what effect the XML model will have on this, but you need as much bandwidth as you can get,..and you don't want to do anything that may impact this. Regards, Alex. "Khosravi, Hormuzd M" wrote: =20 Hi Jon, Rachid Your current XML experiments have only tried Add Routes, which is probably one of the simplest structures to encapsulate and even with that seems like the performance was an order of magnitude less than simple TLV approach. It would be interesting to see the performance for more complex structures which would be part of the FE Model such as DiffServ structures. Thanks Hormuzd -----Original Message----- From: Rachid Nait Takourout (LMC) [ mailto:Rachid.Nait.Takourout@ericsson.ca ] Sent: Friday, March 28, 2003 9:55 AM To: FORCES@PEACH.EASE.LSOFT.COM =20 Subject: Re: [FORCES] XML experience/learning in FACT/TIPC implementation Hi, As Jon said, our XML experience was a test in order to prove the possibilities of this choice. In fact, the performances for each add-route were lower with XML, but the XML parser (it is Expat) was not created specificly for this type of application. So, if we would design an advanced router, the use of different types of NP (Intel, EzChip...) poses the problem of the management of the heterogeneity. XML could provide a generic way to express command that could be independant of APIs like the NPF API. It could be interesting to have a XML based FE Model and protocol which are coherent. Rachid Nait Takourout -----Message d'origine----- De : Alan DeKok [ mailto:alan.dekok@idt.com ] Envoy=E9 : Friday, March 28, 2003 12:30 PM =C0 : FORCES@PEACH.EASE.LSOFT.COM =20 Objet : Re: XML experience/learning in FACT/TIPC implementation Jon Maloy wrote: =20 Hi, Our experiences with XMLas representation language are generally very positive. XML is well fit to express the commands and queries needed in the protocol. =20 There was also an 'xmlconf' or 'netconf' BOF, which met at IETF-56 on Monday. If we decide to use XML as a ForCES protocol, it would seem that there may be significant overlap between the two groups. =20 Our main concern from the beginning was performance, but our experiments indicate that this is not a big problem. =20 Assuming that the machines involved are powerful, and have sufficient memory. As Moore's law shows, this is probably a reasonable assumption, given the timescales involved with creating a new protocol in a working group. =20 With XML each add-route item is around 10 times larger than the corresponding items in the FLEX protocol, and we have indications that this will cause the the whole transfer/parsing process to be an order of magnitude slower than with 'native' FLEX or FACT. =20 The question is then whether this slowdown is significant. If the total bandwidth devoted to ForCES is minimal, then increasing it by a factor of 10 is probably acceptable. =20 So the question we must answer is the following: Is a performance degradation of ~10 times worth the price, given the extra flexibility that XML provides over FLEX/FACT? =20 And given the extra cost of implementing more complicated parsers. For now, it looks expensive to me, but not outlandish. Alan DeKok =2E =20 --------------010906010409040903010908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I think the conclusion should be that we need to continue and widen the
scope of our prototyping.
We must also do some theoretical calculation on hwo much bandwidth
the use of XML will actually require, taking into account its ratio of
of the total traffic load.
If TIPC is chosen as bearer one should also consider that it is capable of
using 4 Ethernets in full load-sharing. With 10 Gbit Ethernet interfaces
and switches there should be some potential....

Do anybody have an overview over the required frequency and distribution of
different types  of commands/queries, both relative to each other an as a part
of the total?

/Jon

Alex Audu wrote:
Also, don't forget other applications that may need a lot bandwidth between CEs
and FEs,
for example, traffic measurement. Typically you'd like your observers in the FEs
to forward
collected flow records to the Export process in the CE for aggregation and
onward export to
an external collector. I don't know what effect the XML model will have on this,
but  you need
as much bandwidth as you can get,..and you don't want to do anything that may
impact this.

Regards,
Alex.

"Khosravi, Hormuzd M" wrote:

  
Hi Jon, Rachid

Your current XML experiments have only tried Add Routes, which is probably
one of the simplest structures to encapsulate and even with that seems like
the performance was an order of magnitude less than simple TLV approach. It
would be interesting to see the performance for more complex structures
which would be part of the FE Model such as DiffServ structures.

Thanks
Hormuzd
-----Original Message-----
From: Rachid Nait Takourout (LMC) [mailto:Rachid.Nait.Takourout@ericsson.ca]

Sent: Friday, March 28, 2003 9:55 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] XML experience/learning in FACT/TIPC implementation

Hi,

        As Jon said, our XML experience was a test in order to prove the
possibilities of this choice. In fact, the performances for each add-route
were lower with XML, but the XML parser (it is Expat) was not created
specificly for this type of application.  So, if we would design an advanced
router, the use of different types of NP (Intel, EzChip...) poses the
problem of the management of the heterogeneity. XML could provide a generic
way to express command that could be independant of APIs like the NPF API.
It could be interesting to have a XML based FE Model and protocol which are
coherent.

Rachid Nait Takourout

-----Message d'origine-----
De : Alan DeKok [mailto:alan.dekok@idt.com]
Envoyé : Friday, March 28, 2003 12:30 PM
À : FORCES@PEACH.EASE.LSOFT.COM
Objet : Re: XML experience/learning in FACT/TIPC implementation

Jon Maloy wrote:
    
Hi,
Our experiences with XMLas representation language are generally
very positive. XML is well fit to express the commands and queries
needed in the protocol.
      
  There was also an 'xmlconf' or 'netconf' BOF, which met at IETF-56 on
Monday.  If we decide to use XML as a ForCES protocol, it would seem
that there may be significant overlap between the two groups.

    
Our main concern from the beginning was performance, but our
experiments indicate that this is not  a big problem.
      
  Assuming that the machines involved are powerful, and have sufficient
memory.  As Moore's law shows, this is probably a reasonable assumption,
given the timescales involved with creating a new protocol in a working
group.

    
With XML each add-route item is around 10 times larger than the
corresponding items in the FLEX protocol, and we have indications
that  this will cause the the whole transfer/parsing process to be an
order of magnitude slower than with 'native' FLEX or FACT.
      
  The question is then whether this slowdown is significant.  If the
total bandwidth devoted to ForCES is minimal, then increasing it by a
factor of 10 is probably acceptable.

    
So the question we must answer is the following: Is a performance
degradation of ~10 times worth the price, given the extra flexibility
that XML provides over FLEX/FACT?
      
  And given the extra cost of implementing more complicated parsers.

  For now, it looks expensive to me, but not outlandish.

  Alan DeKok
.

--------------010906010409040903010908-- 2003 Message-Id: Date: Fri, 28 Mar 2003 14:26:24 +0100 From: Patrick Droz Organization: IBM Research Subject: tentative minutes Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Attached are the tentative minutes from the last IETF. In case you want to have something changes please let me know. I intent to submit them to the IETF server early next week. Regards, Patrick ForCES IETF 56 Meeting Minutes About 100 persons attended the meeting. Thanks to Hormuzd for taking notes. FACT - Ram Gopal Ram presented a protocol overview including the NE model and the message structure, Q Adam - why CE tag if one CE is active? A Ram - cause of multiple CE sets He then showed message classes and the types. Afterwards the association phase including the sequence of operations were shown. Also the states of the elements were introduces. Q Jamal - Is this CE-to-CE or FE-to-FE communication? A Ram - NO, CE-to-FE. Then the normal operation phases were given. Finally some other features were given like 2 phase, command bundling, and high availability (HA). Q XYZ - Can this be used only for post-association? A Ram - yes, but certain configuration needs to be done in pre-associatio= n Q Adam - All IP Address are only 32 bits, is that on purpose? A Ram - No, this need to be fixed Netlink2 - Robert Haas The reasoning why Netlink2 is derived from netlink is because netlink is already widely used in linux systems as a message-based interface between control code (usually running in user space) and forwarding code (kernel space) to perform, for instance, IP routing, ARP, QoS, etc. Netlink2 extends netlink to address the fact that CEs and FEs can be distributed. The Netlink2 header is an extension of the netlink header with slight changes, and supports optional TLVs. FEs and CEs have unique PIDs. Logical PIDs can be used to group FEs and CEs. Netlink2 extends the concept of the netlink wire to Netlink2 wires and bundles that are built with IP unicast and multicast addresses to enable scalability and high-availability. Q XYZ - How do multiple CEs send messages to multiple FEs? A Robert =96 by different multicast addresses Netlink2 has built in reliability, it has a prioritization method, an ACK strategy to confirm messages. It support atomicity, ordering and batching. The flexibility of Netlink2 comes from its wires & bundles. In the current version of the draft there is no capability discovery yet. Q Alex - The draft does not seem to give specifics about configurations.=20 Lots of should/could but no details ? A Jamal - last section talks about this, the draft gives mechanisms,=20 need to add details Q Alex - What about Scalability issues? A Jamal =96 by using broadcast and multicast Q Lorenzo Vicisano (co-chair of reliable multicast WG) - Scalability=20 might be limited by reliability A Robert =96 reliable multicast methods from this WG should be used if ne= eded. FE Model - Ram Gopal Ram showed the FE Block and the block library. On the Issue list he had - topology discovery out of scope, no restriction of FE block layout, control of topology CE or FE? The intend is to provide a bunch of handles and do not represent topology. Q XYZ - what do you mean by logical loops & physical loops? A Ram - physical - layout of board, logical - blocks can have some logic Q Jamal - looping to same instance should be allowed A Ram - yes, this depends on the block properties Q Joel - describe blocks on wire and in doc and need input from WG Q Jamal - no constraint on how many FE blocks can be connected, add some=20 text for this. Q Chair - Has the doc been read? A Quite a few people have read the draft but more people should be involv= ed. Chair =96 Should further discuss the draft on the mailing list TIPC (Telecom Inter Process Communication) - Jon Maloy TIPC is high-speed, reliable message oriented communication service specially designed for cluster environments. They implemented the FACT proposal on top of TPIC and using XML encoding. The protocol has a logical addressing scheme and agile connections. It was claimed that TIPC is easily portable. It runs on different interconnects (over Ethernet, UDP/IP, SCTP/IP). Q Alex - Why TIPC over SCTP, it is already a transport? Q - how does TIPC addressing work on IP? Q - is it used most of the time over Ethernet or over IP ? A Jon - over Ethernet, Q - then why 2 addressing schemes? A =96 for logical addressing TIPC is location transparent, and FE binds to services. At the start of the synchronization the topology detection takes place. Q Jamal - is this built into TIPC ? or in lower transport ? A Jon - yes Demo of FACT/XML over 2 P4 systems Q Alex - what is the latency of the switch? A Jon - currently 1 sec Q Jamal - how big is this protocol? Would it fit on top of a router? A Jon - code size is 15,000 loc Q - why is it inside the kernel? A - for performance reasons --=20 Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 2003 Message-Id: Date: Fri, 28 Mar 2003 14:16:12 -0600 From: Alex Audu Subject: Re: XML experience/learning in FACT/TIPC implementation MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Also, don't forget other applications that may need a lot bandwidth betwe= en CEs and FEs, for example, traffic measurement. Typically you'd like your observers in = the FEs to forward collected flow records to the Export process in the CE for aggregation an= d onward export to an external collector. I don't know what effect the XML model will have o= n this, but you need as much bandwidth as you can get,..and you don't want to do anything that= may impact this. Regards, Alex. "Khosravi, Hormuzd M" wrote: > Hi Jon, Rachid > > Your current XML experiments have only tried Add Routes, which is proba= bly > one of the simplest structures to encapsulate and even with that seems = like > the performance was an order of magnitude less than simple TLV approach= . It > would be interesting to see the performance for more complex structures > which would be part of the FE Model such as DiffServ structures. > > Thanks > Hormuzd > -----Original Message----- > From: Rachid Nait Takourout (LMC) [mailto:Rachid.Nait.Takourout@ericsso= n.ca] > > Sent: Friday, March 28, 2003 9:55 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] XML experience/learning in FACT/TIPC implementati= on > > Hi, > > As Jon said, our XML experience was a test in order to prove th= e > possibilities of this choice. In fact, the performances for each add-ro= ute > were lower with XML, but the XML parser (it is Expat) was not created > specificly for this type of application. So, if we would design an adv= anced > router, the use of different types of NP (Intel, EzChip...) poses the > problem of the management of the heterogeneity. XML could provide a gen= eric > way to express command that could be independant of APIs like the NPF A= PI. > It could be interesting to have a XML based FE Model and protocol which= are > coherent. > > Rachid Nait Takourout > > -----Message d'origine----- > De : Alan DeKok [mailto:alan.dekok@idt.com] > Envoy=E9 : Friday, March 28, 2003 12:30 PM > =C0 : FORCES@PEACH.EASE.LSOFT.COM > Objet : Re: XML experience/learning in FACT/TIPC implementation > > Jon Maloy wrote: > > > > Hi, > > Our experiences with XMLas representation language are generally > > very positive. XML is well fit to express the commands and queries > > needed in the protocol. > > There was also an 'xmlconf' or 'netconf' BOF, which met at IETF-56 on > Monday. If we decide to use XML as a ForCES protocol, it would seem > that there may be significant overlap between the two groups. > > > Our main concern from the beginning was performance, but our > > experiments indicate that this is not a big problem. > > Assuming that the machines involved are powerful, and have sufficient > memory. As Moore's law shows, this is probably a reasonable assumption= , > given the timescales involved with creating a new protocol in a working > group. > > > With XML each add-route item is around 10 times larger than the > > corresponding items in the FLEX protocol, and we have indications > > that this will cause the the whole transfer/parsing process to be an > > order of magnitude slower than with 'native' FLEX or FACT. > > The question is then whether this slowdown is significant. If the > total bandwidth devoted to ForCES is minimal, then increasing it by a > factor of 10 is probably acceptable. > > > So the question we must answer is the following: Is a performance > > degradation of ~10 times worth the price, given the extra flexibility > > that XML provides over FLEX/FACT? > > And given the extra cost of implementing more complicated parsers. > > For now, it looks expensive to me, but not outlandish. > > Alan DeKok. 2003 Message-Id: Date: Fri, 28 Mar 2003 12:54:31 -0500 From: "Rachid Nait Takourout (LMC)" Subject: Re: XML experience/learning in FACT/TIPC implementation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As Jon said, our XML experience was a test in order to prove the = possibilities of this choice. In fact, the performances for each = add-route were lower with XML, but the XML parser (it is Expat) was not = created specificly for this type of application. So, if we would = design an advanced router, the use of different types of NP (Intel, = EzChip...) poses the problem of the management of the heterogeneity. = XML could provide a generic way to express command that could be = independant of APIs like the NPF API. It could be interesting to have a = XML based FE Model and protocol which are coherent. Rachid Nait Takourout -----Message d'origine----- De : Alan DeKok [mailto:alan.dekok@idt.com] Envoy=E9 : Friday, March 28, 2003 12:30 PM =C0 : FORCES@PEACH.EASE.LSOFT.COM Objet : Re: XML experience/learning in FACT/TIPC implementation Jon Maloy wrote: > > Hi, > Our experiences with XMLas representation language are generally > very positive. XML is well fit to express the commands and queries > needed in the protocol. There was also an 'xmlconf' or 'netconf' BOF, which met at IETF-56 on Monday. If we decide to use XML as a ForCES protocol, it would seem that there may be significant overlap between the two groups. > Our main concern from the beginning was performance, but our > experiments indicate that this is not a big problem. Assuming that the machines involved are powerful, and have sufficient memory. As Moore's law shows, this is probably a reasonable = assumption, given the timescales involved with creating a new protocol in a working group. > With XML each add-route item is around 10 times larger than the > corresponding items in the FLEX protocol, and we have indications > that this will cause the the whole transfer/parsing process to be an > order of magnitude slower than with 'native' FLEX or FACT. The question is then whether this slowdown is significant. If the total bandwidth devoted to ForCES is minimal, then increasing it by a factor of 10 is probably acceptable. > So the question we must answer is the following: Is a performance > degradation of ~10 times worth the price, given the extra flexibility > that XML provides over FLEX/FACT? And given the extra cost of implementing more complicated parsers. For now, it looks expensive to me, but not outlandish. Alan DeKok. 2003 Message-Id: Date: Fri, 28 Mar 2003 12:30:07 -0500 From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: XML experience/learning in FACT/TIPC implementation MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jon Maloy wrote: > > Hi, > Our experiences with XMLas representation language are generally > very positive. XML is well fit to express the commands and queries > needed in the protocol. There was also an 'xmlconf' or 'netconf' BOF, which met at IETF-56 on Monday. If we decide to use XML as a ForCES protocol, it would seem that there may be significant overlap between the two groups. > Our main concern from the beginning was performance, but our > experiments indicate that this is not a big problem. Assuming that the machines involved are powerful, and have sufficient memory. As Moore's law shows, this is probably a reasonable assumption, given the timescales involved with creating a new protocol in a working group. > With XML each add-route item is around 10 times larger than the > corresponding items in the FLEX protocol, and we have indications > that this will cause the the whole transfer/parsing process to be an > order of magnitude slower than with 'native' FLEX or FACT. The question is then whether this slowdown is significant. If the total bandwidth devoted to ForCES is minimal, then increasing it by a factor of 10 is probably acceptable. > So the question we must answer is the following: Is a performance > degradation of ~10 times worth the price, given the extra flexibility > that XML provides over FLEX/FACT? And given the extra cost of implementing more complicated parsers. For now, it looks expensive to me, but not outlandish. Alan DeKok. 2003 Message-Id: Date: Fri, 28 Mar 2003 11:07:51 -0800 From: "Khosravi, Hormuzd M" Subject: Re: XML experience/learning in FACT/TIPC implementation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Rachid Your current XML experiments have only tried Add Routes, which is = probably one of the simplest structures to encapsulate and even with that seems = like the performance was an order of magnitude less than simple TLV = approach. It would be interesting to see the performance for more complex structures which would be part of the FE Model such as DiffServ structures. Thanks Hormuzd -----Original Message----- From: Rachid Nait Takourout (LMC) = [mailto:Rachid.Nait.Takourout@ericsson.ca] Sent: Friday, March 28, 2003 9:55 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] XML experience/learning in FACT/TIPC = implementation Hi, As Jon said, our XML experience was a test in order to prove = the possibilities of this choice. In fact, the performances for each = add-route were lower with XML, but the XML parser (it is Expat) was not created specificly for this type of application. So, if we would design an = advanced router, the use of different types of NP (Intel, EzChip...) poses the problem of the management of the heterogeneity. XML could provide a = generic way to express command that could be independant of APIs like the NPF = API. It could be interesting to have a XML based FE Model and protocol which = are coherent. Rachid Nait Takourout -----Message d'origine----- De : Alan DeKok [mailto:alan.dekok@idt.com] Envoy=E9 : Friday, March 28, 2003 12:30 PM =C0 : FORCES@PEACH.EASE.LSOFT.COM Objet : Re: XML experience/learning in FACT/TIPC implementation Jon Maloy wrote: > > Hi, > Our experiences with XMLas representation language are generally > very positive. XML is well fit to express the commands and queries > needed in the protocol. There was also an 'xmlconf' or 'netconf' BOF, which met at IETF-56 on Monday. If we decide to use XML as a ForCES protocol, it would seem that there may be significant overlap between the two groups. > Our main concern from the beginning was performance, but our > experiments indicate that this is not a big problem. Assuming that the machines involved are powerful, and have sufficient memory. As Moore's law shows, this is probably a reasonable = assumption, given the timescales involved with creating a new protocol in a working group. > With XML each add-route item is around 10 times larger than the > corresponding items in the FLEX protocol, and we have indications > that this will cause the the whole transfer/parsing process to be an > order of magnitude slower than with 'native' FLEX or FACT. The question is then whether this slowdown is significant. If the total bandwidth devoted to ForCES is minimal, then increasing it by a factor of 10 is probably acceptable. > So the question we must answer is the following: Is a performance > degradation of ~10 times worth the price, given the extra flexibility > that XML provides over FLEX/FACT? And given the extra cost of implementing more complicated parsers. For now, it looks expensive to me, but not outlandish. Alan DeKok. 2003 Message-Id: Date: Fri, 28 Mar 2003 10:26:47 -0800 From: "Yang, Lily L" Subject: Re: XML experience/learning in FACT/TIPC implementation Comments: To: "Rachid.Nait.Takourout@ericsson.ca" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rachid -- Could you clarify sth for me? What do you mean when you said = "the performances for each add-route were lower with XML"? Lower comparing = with what? What performance metric you were refering to here? Thanks, Lily -----Original Message----- From: Rachid Nait Takourout (LMC) [mailto:Rachid.Nait.Takourout@ericsson.ca] Sent: Friday, March 28, 2003 9:55 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: XML experience/learning in FACT/TIPC implementation Hi, As Jon said, our XML experience was a test in order to prove = the possibilities of this choice. In fact, the performances for each = add-route were lower with XML, but the XML parser (it is Expat) was not created specificly for this type of application. So, if we would design an = advanced router, the use of different types of NP (Intel, EzChip...) poses the problem of the management of the heterogeneity. XML could provide a = generic way to express command that could be independant of APIs like the NPF = API. It could be interesting to have a XML based FE Model and protocol which = are coherent. Rachid Nait Takourout -----Message d'origine----- De : Alan DeKok [mailto:alan.dekok@idt.com] Envoy=E9 : Friday, March 28, 2003 12:30 PM =C0 : FORCES@PEACH.EASE.LSOFT.COM Objet : Re: XML experience/learning in FACT/TIPC implementation Jon Maloy wrote: > > Hi, > Our experiences with XMLas representation language are generally > very positive. XML is well fit to express the commands and queries > needed in the protocol. There was also an 'xmlconf' or 'netconf' BOF, which met at IETF-56 on Monday. If we decide to use XML as a ForCES protocol, it would seem that there may be significant overlap between the two groups. > Our main concern from the beginning was performance, but our > experiments indicate that this is not a big problem. Assuming that the machines involved are powerful, and have sufficient memory. As Moore's law shows, this is probably a reasonable = assumption, given the timescales involved with creating a new protocol in a working group. > With XML each add-route item is around 10 times larger than the > corresponding items in the FLEX protocol, and we have indications > that this will cause the the whole transfer/parsing process to be an > order of magnitude slower than with 'native' FLEX or FACT. The question is then whether this slowdown is significant. If the total bandwidth devoted to ForCES is minimal, then increasing it by a factor of 10 is probably acceptable. > So the question we must answer is the following: Is a performance > degradation of ~10 times worth the price, given the extra flexibility > that XML provides over FLEX/FACT? And given the extra cost of implementing more complicated parsers. For now, it looks expensive to me, but not outlandish. Alan DeKok. 2003 Message-Id: Date: Fri, 28 Mar 2003 09:58:09 -0500 From: Jon Maloy Subject: Re: XML experience/learning in FACT/TIPC implementation Comments: To: "Yang, Lily L" Comments: cc: "Rachid Nait Takourout (LMC)" , "Laurent Marchand (LMC)" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Our experiences with XMLas representation language are generally very positive. XML is well fit to express the commands and queries needed in the protocol. Our main concern from the beginning was performance, but our experiments indicate that this is not a big problem. The specific measurements we did here shows that it was possible to transfer and parse 42000 "add-routes"/s, when bundling 40 add-routes into each transferred message. This measurements were performed between two 2 GHz P-4:s. With XML each add-route item is around 10 times larger than the corresponding items in the FLEX protocol, and we have indications that this will cause the the whole transfer/parsing process to be an order of magnitude slower than with 'native' FLEX or FACT. We may find better parsers, and there is still a potential for further optimizations in the transport plugin code, but frankly I don't think this ratio will change significantly. So the question we must answer is the following: Is a performance degradation of ~10 times worth the price, given the extra flexibility that XML provides over FLEX/FACT? Regards /Jon Yang, Lily L wrote: >Hi, Jon -- > >At last week's IETF meeting you presented Ericsson's FACT/TIPC >implementation and demo. That was very interesting. One of the motivations >of doing this implementation you mentioned is to understand/experiment with >using XML as the FE model data representation language. I am very anxious >to know what is your learning/finding in that respect? As you know, one of >the questions we are struggling with on FE model is which modeling languauge >we should pick eventually. Can you share with the group your >learning/thoughts on this topic? > >Thanks, > >Lily > > 2003 Message-Id: Date: Thu, 27 Mar 2003 10:44:48 -0800 From: "Putzolu, David" Subject: Summary, IETF ForCES Meeting @ IETF 56 Comments: To: Alex Zinin , "Bill Fenner (fenner@research.att.com)" Comments: cc: "Patrick Droz (dro@zurich.ibm.com)" MIME-Version: 1.0 Content-Type: text/plain ForCES met at IETF 56 for one hour with an attendance of approximately one hundred people. Two protocol drafts (NetLink2, FACT) where presented as potential candidates for the ForCES protocol. These drafts will be reviewed over the next three months, as will any additional protocol drafts submitted, for suitability as the basis of the ForCES protocol. In addition to these drafts, TIPC, a lightweight transport protocol, was presented for review for potential inclusion in the ForCES effort. Finally, a revised model individual contribution was presented. This draft has been reviewed previously and will be considered for inclusion as a working group document once the new revision has been properly circulated. 2003 Message-Id: Date: Wed, 26 Mar 2003 10:19:24 -0800 From: "Yang, Lily L" Subject: XML experience/learning in FACT/TIPC implementation Comments: To: "jon.maloy@ericsson.com" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, Jon -- At last week's IETF meeting you presented Ericsson's FACT/TIPC implementation and demo. That was very interesting. One of the motivations of doing this implementation you mentioned is to understand/experiment with using XML as the FE model data representation language. I am very anxious to know what is your learning/finding in that respect? As you know, one of the questions we are struggling with on FE model is which modeling languauge we should pick eventually. Can you share with the group your learning/thoughts on this topic? Thanks, Lily 2003 Message-Id: Date: Mon, 24 Mar 2003 16:02:52 +0800 From: Hong Li Subject: Re: ForCES Agenda, MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksDQoNCklzIHRoZXJlIGFueWJvZHkgd2hvIGNhbiB0ZWxsIG1lIGhvdyB0byBnZXQgdGhlIHBh cGVyIG9yICBvdGhlciBraW5kIG9mIGRvY3VtZW50cyBvbiAgVElQSUMgVGVsZWNvbSBJbnRlciBQ cm9jZXNzIENvbW11bmljYXRpb24gYnkgSm9uIE1hbG95IGluIHRoZSBtZWV0aW5nPw0KDQpCZXN0 IFJlZ2FyZHMsDQpMaSBIb25nDQpDb21wdXRlciBTY2llbmNlIGFuZCBUZWNobm9sb2d5IERlcGFy dG1lbnQgb2YNClRzaW5naHVhIFVuaXZlcnNpdHksQmVpamluZy5DaGluYQ0KbGlob25nMDFAbWFp bHMudHNpbmdodWEuZWR1LmNuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZy b206ICJQYXRyaWNrIERyb3oiIDxkcm9AenVyaWNoLmlibS5jb20+DQpUbzogPEZPUkNFU0BQRUFD SC5FQVNFLkxTT0ZULkNPTT4NClNlbnQ6IEZyaWRheSwgTWFyY2ggMTQsIDIwMDMgNTozMCBQTQ0K U3ViamVjdDogRm9yQ0VTIEFnZW5kYSwNCg0KDQo+IGF0dGFjaGVkIGlzIHRoZSBhZ2VuZGEgZm9y IHRoZSB1cGNvbWluZyBtZWV0aW5nLiBXZSBoYWQgdG8NCj4gc3F1ZWV6ZSB0aGUgdGltZXMgYSBi aXQgdG8gZml0IGluIHRoZSBsYXRlc3QgcmVxdWVzdHMuDQo+IA0KPiBSZWdhcmRzLA0KPiBQYXRy aWNrDQo+IA0KPiBGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbiAoRm9y Q0VTKQ0KPiANCj4gVHVlc2RheSBNYXJjaCAxOHRoIDIwMDMgYXQgMTQ6MTUgLSAxNToxNQ0KPiA9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IA0KPiBDSEFJUlM6ICAg RGF2aWQgUHV0em9sdSA8RGF2aWQuUHV0em9sdUBpbnRlbC5jb20+DQo+ICAgICAgICAgICAgUGF0 cmljayBEcm96IDxkcm9AenVyaWNoLmlibS5jb20+DQo+IA0KPiBBRHM6ICAgICAgQmlsbCBGZW5u ZXIgPGZlbm5lckByZXNlYXJjaC5hdHQuY29tPg0KPiAgICAgICAgICAgIEFsZXggWmluaW4gPHpp bmluQHBzZy5jb20+DQo+IA0KPiBBR0VOREE6DQo+IA0KPiAxNyBtaW4gLSBGb3J3QXJkaW5nIGFu ZCBDb250cm9sIEVsZW1lblQgcHJvdG9jb2wgKEZBQ1QpDQo+IGRyYWZ0LWdvcGFsLWZvcmNlcy1m YWN0LTAzLnR4dA0KPiBBbGV4IC8gUmFtDQo+IA0KPiAxNyBtaW4gLSBOZXRsaW5rMiBhcyBGb3JD RVMgcHJvdG9jb2wNCj4gZHJhZnQtamhzcmhhLWZvcmNlcy1uZXRsaW5rMi0wMC50eHQNCj4gUm9i ZXJ0IC8gSmFtYWwNCj4gDQo+IDE3IG1pbiAtIEZvckNFUyBGb3J3YXJkaW5nIEVsZW1lbnQgRnVu Y3Rpb25hbCBNb2RlbA0KPiBkcmFmdC15YW5nLWZvcmNlcy1tb2RlbC0wMS50eHQNCj4gUmFtDQo+ IA0KPiAxMCBtaW4gLSBUSVBJQyBUZWxlY29tIEludGVyIFByb2Nlc3MgQ29tbXVuaWNhdGlvbg0K PiBQcm90b3R5cGUgSW1wbGVtZW50YXRpb24NCj4gSm9uIE1hbG95DQo+IA0K 2003 Message-Id: Date: Mon, 24 Mar 2003 13:38:55 -0500 From: Jon Maloy Subject: Re: ForCES Agenda, MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit You can download it from here: http://tipc.sourceforge.net/ Regards /Jon Maloy Hong Li wrote: >Hi, > >Is there anybody who can tell me how to get the paper or other kind of documents on TIPIC Telecom Inter Process Communication by Jon Maloy in the meeting? > >Best Regards, >Li Hong >Computer Science and Technology Department of >Tsinghua University,Beijing.China >lihong01@mails.tsinghua.edu.cn > > >----- Original Message ----- >From: "Patrick Droz" >Sent: Friday, March 14, 2003 5:30 PM >Subject: ForCES Agenda, > > > > >>attached is the agenda for the upcoming meeting. We had to >>squeeze the times a bit to fit in the latest requests. >> >>Regards, >>Patrick >> >>Forwarding and Control Element Separation (ForCES) >> >>Tuesday March 18th 2003 at 14:15 - 15:15 >>======================================== >> >>CHAIRS: David Putzolu >> Patrick Droz >> >>ADs: Bill Fenner >> Alex Zinin >> >>AGENDA: >> >>17 min - ForwArding and Control ElemenT protocol (FACT) >>draft-gopal-forces-fact-03.txt >>Alex / Ram >> >>17 min - Netlink2 as ForCES protocol >>draft-jhsrha-forces-netlink2-00.txt >>Robert / Jamal >> >>17 min - ForCES Forwarding Element Functional Model >>draft-yang-forces-model-01.txt >>Ram >> >>10 min - TIPIC Telecom Inter Process Communication >>Prototype Implementation >>Jon Maloy >> >> >> 2003 Message-Id: Date: Mon, 24 Mar 2003 09:05:09 -0600 From: Alex Audu Subject: Re: ForCES Agenda, MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit http://tipc.sourceforge.net/ Hong Li wrote: > Hi, > > Is there anybody who can tell me how to get the paper or other kind of documents on TIPIC Telecom Inter Process Communication by Jon Maloy in the meeting? > > Best Regards, > Li Hong > Computer Science and Technology Department of > Tsinghua University,Beijing.China > lihong01@mails.tsinghua.edu.cn > > ----- Original Message ----- > From: "Patrick Droz" > Sent: Friday, March 14, 2003 5:30 PM > Subject: ForCES Agenda, > > > attached is the agenda for the upcoming meeting. We had to > > squeeze the times a bit to fit in the latest requests. > > > > Regards, > > Patrick > > > > Forwarding and Control Element Separation (ForCES) > > > > Tuesday March 18th 2003 at 14:15 - 15:15 > > ======================================== > > > > CHAIRS: David Putzolu > > Patrick Droz > > > > ADs: Bill Fenner > > Alex Zinin > > > > AGENDA: > > > > 17 min - ForwArding and Control ElemenT protocol (FACT) > > draft-gopal-forces-fact-03.txt > > Alex / Ram > > > > 17 min - Netlink2 as ForCES protocol > > draft-jhsrha-forces-netlink2-00.txt > > Robert / Jamal > > > > 17 min - ForCES Forwarding Element Functional Model > > draft-yang-forces-model-01.txt > > Ram > > > > 10 min - TIPIC Telecom Inter Process Communication > > Prototype Implementation > > Jon Maloy > > 2003 Message-Id: Date: Fri, 14 Mar 2003 10:30:10 +0100 From: Patrick Droz Organization: IBM Research Subject: ForCES Agenda, Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit attached is the agenda for the upcoming meeting. We had to squeeze the times a bit to fit in the latest requests. Regards, Patrick Forwarding and Control Element Separation (ForCES) Tuesday March 18th 2003 at 14:15 - 15:15 ======================================== CHAIRS: David Putzolu Patrick Droz ADs: Bill Fenner Alex Zinin AGENDA: 17 min - ForwArding and Control ElemenT protocol (FACT) draft-gopal-forces-fact-03.txt Alex / Ram 17 min - Netlink2 as ForCES protocol draft-jhsrha-forces-netlink2-00.txt Robert / Jamal 17 min - ForCES Forwarding Element Functional Model draft-yang-forces-model-01.txt Ram 10 min - TIPIC Telecom Inter Process Communication Prototype Implementation Jon Maloy 2003 Message-Id: Date: Wed, 12 Mar 2003 17:05:15 -0800 From: "Yang, Lily L" Subject: new FE model draft for review MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2E8FC.9B500330" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2E8FC.9B500330 Content-Type: text/plain; charset="iso-8859-1" Hi, all -- Attached is a new revision of the FE model individual contribution. We were not able to complete it before the deadline for this IETF meeting, but we will submit it officially after the IETF S.F. meeting. Here is a summary of the changes of v02 over 01: * Most significant change is in Section 3. Back in Jan, there was a lively discussion over the FE model in the mailing list and we have revised this section to incorporate the feedback we got. We believe the most contentious issue raised so far is on the configurability of FE topology. So we try to address that and clearly spell out what kind of config we think is feasible and should be supported by ForCES, and what is out of scope. * Minor change through out the doc, mostly editorial. As always, feedback is most welcome. Thanks, Lily <> ------_=_NextPart_000_01C2E8FC.9B500330 Content-Type: text/plain; name="draft-yang-forces-model-02.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-yang-forces-model-02.txt" Internet Draft L. Yang=20 Expiration: Sept 2003 Intel Labs=20 File: draft-yang-forces-model-02.txt J. Halpern=20 Working Group: ForCES =20 R. Gopal=20 Nokia=20 R. Dantu=20 Univ. of North = Texas=20 March 2003=20 = =20 =20 =20 ForCES Forwarding Element Functional Model=20 =20 =20 =20 draft-yang-forces-model-02.txt=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance = with=20 all provisions of Section 10 of RFC2026. Internet-Drafts are=20 working documents of the Internet Engineering Task Force = (IETF), its=20 areas, and its working groups. Note that 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 Abstract=20 =20 This document defines a functional model for forwarding = elements=20 (FEs) used in the Forwarding and Control Plane Separation = (ForCES)=20 protocol. This model is used to describe the capabilities and = state=20 of ForCES forwarding elements within the context of the ForCES=20 protocol, so that ForCES control elements (CEs) can control the = FEs=20 accordingly. The model is to specify what logical functions are = present in the FEs, what capabilities these functions support, = and=20 in what order these functions are or can be performed. The=20 forwarding element model defined herein is intended to satisfy = the=20 requirements specified in the ForCES requirements draft = [FORCES- REQ]. Using this model, predefined or vendor specific logical=20 =20 =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 functions can be expressed and configured. However, the = definition=20 of these individual functions are not described and defined in = this=20 document. =20 =20 Table of Contents =20 =20 = Abstract...........................................................1=20 1. = Definitions.....................................................2=20 2. Motivation and Requirements of FE = model.........................3=20 3. Configurability of FE = Model.....................................3=20 4. FE = Model........................................................8=20 4.1. FE = Blocks..................................................8=20 4.2. FE Block = Library...........................................9=20 4.2.1. QoS = Functions.........................................9=20 4.2.2. Generic Filtering = Functions..........................12=20 4.2.3. Vendor Specific = Functions............................12=20 4.2.4. Port = Functions.......................................12=20 4.2.5. Forwarding = Functions.................................13=20 4.2.6. High-Touch Functions...............................= ..14=20 4.2.7. Security = Functions...................................14=20 4.2.8. Off-loaded = Functions.................................14=20 4.3. FE Stage and Directed Graph of = FE.........................14=20 4.3.1. Basic = Concepts.......................................15=20 4.3.2. Topological versus Encoded State = Approaches..........15=20 4.3.3. Cascading FE = Blocks..................................18=20 5. Data Modeling and = Representation...............................18=20 6. Security = Considerations........................................19=20 7. Intellectual Property = Right....................................19=20 8. IANA = consideration.............................................19=20 9. Normative = References...........................................20=20 10. Informative = References........................................20=20 11. = Acknowledgments...............................................21=20 12. Authors' = Addresses............................................21=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 1. Definitions=20 =20 A set of terminology associated with the ForCES requirements is = defined in [FORCES-REQ] and is not copied here. The following = list=20 of terminology is relevant to the FE model defined in this = document.=20 =20 Datapath -- A conceptual path taken by packets within the = forwarding=20 plane, inside an FE. There might exist more than one datapath = within=20 an FE.=20 =20 Forwarding Element (FE) Block -- An abstraction of the basic = packet=20 processing logical functions in the datapath. It is the = building=20 =20 Yang, et. al. Expires May 2003 [Page 2] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 block of FE functionality. This concept abstracts away=20 implementation details from the parameters of interest for=20 configuration, control and management by CE. =20 =20 Forwarding Element (FE) Stage -- Representation of an FE block=20 instance in a FE's datapath. As a packet flows through an FE = along a=20 datapath, it flows through one or multiple distinct stages, = with=20 each stage implementing an instance of a certain logical = function=20 block. There may be multiple instances of the same functional = block=20 in a FE's datapath. =20 =20 Forwarding Element (FE) Topology -- Representation of how the = FE=20 blocks are interconnected and placed along the datapath.=20 =20 2. Motivation and Requirements of FE model=20 =20 The ForCES architecture allows Forwarding Elements (FEs) of = varying=20 functionality to participate in a ForCES network element (NE). = The=20 implication of this varying functionality is that CEs can make = only=20 minimal assumptions about the functionality provided by its = FEs. =20 Before CEs can configure and control the forwarding behavior of = FEs,=20 CEs need to query and discover the capabilities and states of = their=20 FEs. [FORCES-REQ] mandates that this capabilities and states=20 information be expressed in the form of an FE model, and this = model=20 will be used as the basis for CEs to control and manipulate = FEs'=20 behavior via ForCES protocol. =20 =20 [FORCES-REQ] describes all the requirements placed on the FE = model=20 in detail. We provide a brief summary here to highlight some of = the=20 design issues we face. =20 . The FE model MUST express what logical functions can be = applied=20 to packets as they pass through an FE.=20 . The FE model MUST be capable of supporting/allowing = variations=20 in the way logical functions are implemented on an FE. =20 . The model MUST be capable of describing the order in which=20 these logical functions are applied in a FE. =20 . The FE model SHOULD be extendable and should have provision = to=20 express new or vendor specific logical functions.=20 . The FE model SHOULD be able to support minimal set of = logical=20 functions that are already identified, such as port = functions,=20 forwarding functions, QoS functions, filtering functions, = high- touch functions, security functions, vendor-specific = functions=20 and off-loaded functions. =20 =20 3. Configurability of FE Model=20 =20 Since the motivation of an FE model is to allow the CEs later = to=20 control and configure the FEs' behavior via ForCES protocol, it = becomes essential to examine and understand what kind of = control and=20 configuration the CEs might do to the FEs. It is also equally=20 essential to understand how configurable or programmable FEs = are=20 today and will be in the near future. =20 =20 =20 Yang, et. al. Expires May 2003 [Page 3] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 To understand the issue better, it is helpful to make a = distinction=20 between two different kinds of FE models =96 the FE state model = and FE=20 capability model. =20 =20 The FE state model describes the current state of the FE, that = is,=20 the instantaneous values or operational behavior of the FE. The = FE=20 state model presents the snapshot view of the FE to the CE. On = the=20 other hand, the FE capability model describes the configurable=20 capabilities and capacities of an FE in terms of variations of=20 functions supported or limitations contained. Conceptually FE=20 capability model presents the many possible states allowed on = an FE=20 with capacity information indicating certain quantitative = limits or=20 constraints, such as how many classifiers the FE can handle, = how=20 many queues, and how many buffer pools the FE can support, how = many=20 meters the FE can provide. The information on the capabilities = and=20 capacities of the FE helps the CE to make intelligent decision = on=20 the configuration it wants to request on the FE. So the=20 configuration is the desirable state that the FE should be in.=20 Figure 1 shows the concepts of FE state, capabilities, = capacities=20 and configuration in the context of CE-FE communication via = ForCES=20 protocol.=20 =20 +-------+ = +-------+=20 | | FE capabilities/capacity: what it can be.| = |=20 | |<-------------------------------------- --| = |=20 | | | = |=20 | CE | FE state: what it is now. | FE = |=20 | |<-----------------------------------------| = |=20 | | | = |=20 | | FE configuration: what it should be. | = |=20 | |----------------------------------------->| = |=20 +-------+ = +-------+=20 =20 Figure 1. Illustration of FE state, capabilities, capacities = and=20 configuration in the context of CE-FE communication via = ForCES.=20 =20 For example, using the FE state model, an FE may be described = to its=20 CE as the following: =20 - on a given port the packets are classified using a given=20 classification filter;=20 - the given classifier results in packets being metered in a = certain=20 way, and then marked in a certain way;=20 - the packets coming from specific markers are delivered into a = shared queue for handling, while other packets are delivered to = a=20 different queue;=20 - a specific scheduler with specific behavior and parameters = will=20 service these collected queues.=20 =20 On the other hand, the capability model may describe the FE at = the=20 coarsest level such as:=20 - this FE can handle IPv4 and IPv6 forwarding;=20 =20 Yang, et. al. Expires May 2003 [Page 4] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 - this FE can perform classification on the following fields: = source=20 IP address, destination IP address, source port number, = destination=20 port number, etc;=20 - this FE can perform metering;=20 - this FE can handle up to N queues (capacity);=20 - this FE can add and remove encapsulating headers of types=20 including IPSec, GRE, L2TP.=20 =20 Conceptually, two levels of information may be represented in = the FE=20 model. The first level is the individual FE functional blocks, = like=20 classifier, meter, encapsulator, etc. The second level = information=20 is about how these individual blocks are placed and = interconnected=20 along the datapath to deliver a complete forwarding plane = service.=20 Such interconnection is referred to as FE topology. =20 =20 In order for ForCES to be useful at all, at the very minimum, = the=20 individual FE functional blocks must be configurable by CEs. So = each=20 FE functional block must be modeled with a set of configurable=20 parameters that can be manipulated by CEs. =20 =20 Where it gets more complicated and controversial is for the=20 capability model to cope with the configuration issues of the = FE=20 topology. For example, can FE be flexible enough to allow a new = datapath being added on the fly, or an old datapath being = deleted?=20 Can FE be reconfigured into a totally different topology? Even = if=20 such powerful programmability exists in FE, the other question = is=20 whether CE can be intelligent enough to use such dynamic = information=20 on the fly to construct totally different NE applications. As = we=20 ponder upon these questions, it becomes clear that there is a = wide=20 spectrum of configurability exists at least theoretically for = FE=20 model. In order to find a sweet spot in such a wide spectrum = for=20 ForCES, it is necessary to examine more carefully the kinds of=20 control and configuration that the CEs may do to the FEs at the = graph topology level and understand issues like implementation=20 feasibility, potential benefits, and additional design = complexity. =20 =20 One extreme of the spectrum is to disallow any kind of topology = reconfiguration. Therefore, the CE can only control FE=92s = behavior by=20 manipulating the parameters for each individual function, but = it=20 cannot change either the datapath or the functions along each=20 datapath. We call this "static FE" control and configuration,=20 because the FE topology remains static during its lifetime. For = example, Figure 4 and 6 each show an FE configuration example = by=20 representing the processing steps in a directed graph=20 interconnecting all the functional stages that packets can = possibly=20 traverse. If such a configuration remains static during FE's=20 lifetime, then CE can only control the behavior of the = forwarding=20 plance by manipulating the properties of each FE functional = block,=20 for example, the routing table in the LPM forwarder in Figure = 4, or=20 the token bucket parameters associated with meter1 in Figure 6. = However, the CE cannot reconfigure the graph topology = dynamically,=20 such as adding another meter or queue onto the FE in Figure 6 = on the=20 fly.=20 =20 Yang, et. al. Expires May 2003 [Page 5] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 =20 For this kind of static control and configuration purpose, the = FE=20 model will include the =93dials and knobs=94 (i.e., the = parameters or=20 attributes) that each function allows CE to manipulate. It = should=20 also include the statistics and events that FEs can collect and = report to CEs. Even for such a =93static FE=94, some capability = model at=20 the individual functions level may be desirable to convey the=20 flexibility of each function. Even though the CE cannot change = the=20 graph, it is still useful for the FE model to describe how the = graph=20 is connected to the CE. For example, the CE may want to = validate the=20 graph to ensure that the FEs can indeed deliver the expected = packet=20 processing functions. Sometimes it is also important for the CE = to=20 know the relative placement of the individual FE blocks because = it=20 may do things differently depending on the order of the blocks. = An=20 obvious example of such is when the FE has 2 functional blocks, = an=20 IPv4 block followed by a NAT block, its necessary to know the = order=20 in which these blocks are linked in order to configure them. A = NAT=20 function may change a packet's source or destination IP = address. =20 Any number of other logical functions (e.g., layer 3 = forwarding,=20 ingress/egress firewall) may make use of the source or = destination=20 IP address when making decisions. The CE needs to know whether = to=20 configure these logical functions with the pre-NAT or post-NAT = IP=20 address. However, a lot of other information may not be = necessary if=20 only static FEs are supported, for example the packet formats=20 between meter1 and counter1 in Figure 6, because such = information is=20 only useful when the graph can be re-configured dynamically on = the=20 fly. =20 =20 Such static configuration is certainly feasible and common with = today=92s technologies. It still requires the FE model to = represent=20 both the individual FE blocks and the FE topology. It also = requires=20 certain capability information at the individual block level to = support limited programmability, but it does not require = capability=20 information at the topology level because the interconnection = is not=20 configurable. So it is a relatively simple model and can = readily=20 support most of the applications exist today. The question now=20 becomes =93is this enough?=94 The emergence of network = processors=20 promises much greater programmability and hence flexibility = than=20 what ASICs can offer and so it is important for ForCES to stay=20 current or even a little bit ahead of the technology curve in = order=20 to stay relevant in the market place. Therefore, it is also=20 necessary to examine the possibility of dynamically reconfigure = the=20 FE topology.=20 =20 In contrast to the complete static FE model, it is easy to = envision,=20 at least theoretically, that the other extreme is to support=20 ultimate flexibility for the CE to reconfigure the FE topology=20 however it wants to. It is also not hard to realize that such=20 flexibility is impossible in practice, because no FE will allow = every possible configuration of any possible number of graph=20 elements. It is also almost impossible in the near future for = the CE=20 to have the intelligence to interpret any dynamic topology and=20 construct the network services or applications correspondingly. = =20 Yang, et. al. Expires May 2003 [Page 6] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 Therefore it is clear that ForCES should not aimed to support = such=20 ultimate reconfigurability either. We believe the sweet spot=20 suitable for ForCES lies somewhere in the middle between these = two=20 extremes of the spectrum. =20 =20 If we start from the static end of the spectrum and move = gradually=20 toward the dynamic end, we can examine what kinds of dynamic=20 configuration are actually feasible with today and tomorrow=92s = technologies. Using Figure 6 as an example again, instead of=20 presenting the static FE graph to the CE, the FE can convey its = capabilities to the CE by telling "this FE can support one=20 classifier with up to N filters. This FE can also support up to = M=20 meters, X queues, etc." Given a CE that understands DiffServ, = it=20 will understand that for an AF service it will need a = classifier (to=20 select which traffic gets the service), a meter, and a set of=20 markers on the ingress path. It will also understand that for = the=20 egress path it will need a mark sensitive queue selector and a = mark=20 sensitive RED element if it has one and wants to use it. It = may=20 well have logic that changes the input behavior if the = available=20 outputs do not have mark sensitive RED. So given all these=20 application (i.e., DiffServ in this case) specific knowledge on = the=20 CE, it is possible for the CE to configure the graph in Figure = 6 and=20 implement some variants of it instead. For example, the = classifier=20 may classify the packets into three instead of four datapath, = and=20 one of the original four datapath may be deleted. Adding new=20 datapath to allow for more fine-grained classification and = queuing=20 control is also possible, given that the FE has the capacity.=20 Manipulating the individual datapath is also possible, as long = as=20 the interconnection still makes sense for the DiffServ-aware = CE. How=20 the CE interprets and validates the graph is outside of the = scope of=20 FE model. But we believe it is feasible for the CE to be given = a set=20 of descriptions along the line of DiffServ model, which defines = the=20 actual processing required, and then look at the capabilities = of the=20 FE and determine whether it can deploy the service. =20 =20 To support such reconfigurability, clearly the FE model = requires=20 more powerful capability model than the static FE model. FE = topology=20 becomes an essential component in the FE model. The information = on=20 capacity, linkage flexibility and constraints between the = blocks is=20 also very important to the CE to build a dynamic FE graph that = makes=20 sense. While one could try to build an object model for = representing=20 such capabilities in full, other efforts have found this to be = a=20 significant undertaking. A middle of the road approach is to = define=20 coarse-grained capabilities and simple capacity measures. = Then, if=20 the CE attempts to instruct the FE to set up some specific = behavior=20 it is not capable of, the FE will return an error indicating = the=20 problem. =20 =20 So in summary of the discussion so far, the FE model proposed = in=20 this document intends to fully support the static FE control = and=20 configuration at the minimum. It is also our intention to allow = dynamic FE control and configuration to a certain degree when = it=20 makes sense, as illustrated by various examples. Toward that = end,=20 =20 Yang, et. al. Expires May 2003 [Page 7] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 the FE model must represent both the individual functional = blocks=20 and the topology of the blocks. The FE model must also include=20 sufficient capability and capacity information to support=20 flexibility in most application domains.=20 =20 4. FE Model=20 =20 This section proposes a ForCES FE model to satisfy all the=20 requirements in [FORCES-REQ] for FE control and configuration. = The=20 approach taken is to model the FE datapath(s) and its packet=20 treatment behavior via a directional graph where each node in = the=20 graph is an instance of a well-defined logical function block. = =20 The FE model defines a generic FE block akin to an abstract = base=20 class in object-oriented terminology. The generic FE block = contains=20 basic information like block type and textual description of = the=20 block function. Based on this generic FE block, a set of = well-known=20 FE logical functions are defined with additional state and=20 capability information pertinent to each specific function. A = name=20 space is used to associate a unique name or ID with each type = of FE=20 block. New logical functions can also be added later to = accommodate=20 future innovation in the forwarding plane, as long as the new=20 functions are modeled as an FE block. With such a set of basic = building blocks defined, any FE can be modeled by a directional = graph where each node is an instance of an FE block, = representing a=20 processing stage in the packet datapath. Each node contains=20 information like block name or ID (indicating the block type), = stage=20 ID (local to FE), number of downstream blocks and a list of the = stage IDs of those downstream blocks. =20 =20 The rest of this section is devoted to describe the informal = data=20 model of FE. The description here is intended to be abstract = and=20 conceptual, and examples are used for illustration purpose = only.=20 Separate document(s) will serve as specifications by using a = formal=20 data modeling language and those specifications should be = consistent=20 with the conceptual model described here. =20 =20 4.1. FE Blocks=20 =20 The generic FE block is the basic building block of the FE = model,=20 like an abstract base class in object-oriented terminology. = Actual=20 FE logical functions like classifiers, IPv4 forwarders and = meters=20 are examples of real FE blocks derived from the generic FE = block=20 concept. =20 =20 A well-defined block has a well-defined packet processing = behavior=20 and a well-defined set of state and capabilities that CE can=20 potentially configure or control via ForCES. A namespace is = needed=20 to specify different types of blocks. The namespace assigns = either a=20 unique ID or label to each distinct block type. Such a = namespace=20 must be extensible so that new functions can be easily added = later. =20 =20 Therefore, the following defines a generic FE Block:=20 =20 Yang, et. al. Expires May 2003 [Page 8] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 - block ID or label which uniquely identifies the block type;=20 - textual description of block function. =20 =20 4.2. FE Block Library=20 =20 We expect a small set of well-understood FE functional blocks = to be=20 defined initially. Such a set of blocks can be viewed as a FE = block=20 library. The minimum set of FE functions required in = [FORCES-REQ]=20 must be part of this library. It is expected that new FE blocks = would be defined and added into this library over time.=20 =20 The actual model for each functional block may differ and = contains=20 information pertinent to the semantics of the function itself.=20 However, some general guideline is still useful. For example,=20 typically it is important to specify information such as:=20 - how many inputs it takes and what kinds of packets and meta = data=20 it takes for each input;=20 - how many outputs it produces and what kind of packets and = meta=20 data it emits for each output;=20 - the packet processing (such as modification) behavior;=20 - what information is programmed into it (e.g., LPM list, next = hop=20 list, WRED parameters, etc.) and what parameters among them are = configurable; =20 - what statistics it keeps (e.g., drop count, CRC error count,=20 etc.); =20 - what events it can throw (e.g., table miss, port down, etc.). = =20 This document only intends to describe the conceptual FE model = and=20 illustrate it with some examples. However, it is not the = intention=20 of this document to define any specific block or the library = itself.=20 Separate document(s) would be written to do that. The minimum = set of=20 FE functions required in [FORCES-REQ] is listed and discussed=20 briefly in the following subsections. Several working groups in = the=20 IETF have already done some relevant work in modeling the=20 provisioning policy data for some of the functions we are = interested=20 in, for example, DiffServ (Differentiated Services) PIB = [DS-PIB],=20 IPSec PIB [IPSEC-PIB]. Whenever possible, we should try to = reuse the=20 work done elsewhere instead of reinventing the wheels.=20 =20 4.2.1. QoS Functions=20 =20 The IETF community has already done some work in modeling the = QoS=20 functions in the datapath. The IETF DiffServ working group has=20 defined an informal data model [RFC3290] for QoS-related = functions=20 like classification, metering, marking, actions of marking,=20 dropping, counting and multiplexing, queueing, etc. The latest = work=20 on DiffServ PIB (Policy Information Base) [DS-PIB] defines a = set of=20 provisioning classes to provide policy control of resources=20 implementing the Diferentiated Services Architecture. DiffServ = PIB=20 also has an element of capability flavor in it that can = potentially=20 enable more dynamic and intelligent configuration of individual = functions and the interconnection of the functions. The IETF = Policy=20 Framework working group is also defining an informational model = =20 Yang, et. al. Expires May 2003 [Page 9] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 [QDDIM] to describe the QoS mechanisms inherent in different = network=20 devices, including hosts. This model is intended to be used = with the=20 QoS Policy Information Model [QPIM] to model how policies can = be=20 defined to manage and configure the QoS mechanisms present in = the=20 datapath of devices.=20 =20 Unclassified classified=20 traffic traffic=20 +------------+=20 | |--> match Filter1 --> OutputA=20 ------->| classifier |--> match Filter2 --> OutputB=20 | |--> no match --> OutputC=20 +------------+=20 =20 Figure 2. An Example Classifier Using DiffServ Model=20 =20 We use the classifier defined in [RFC3290] as an example to=20 illustrate the DiffServ model. "Classifiers are 1:N (fan-out)=20 devices: they take a single traffic stream as input and = generate N=20 logically separate traffic streams as output. Classifiers are=20 parameterized by filters and output streams. Packets from the = input=20 stream are sorted into various output streams by filters which = match=20 the contents of the packet or possibly match other attributes=20 associated with the packet." To further define filters: "A = filter=20 consists of a set of conditions on the component values of a=20 packet's classification key (the header values, contents, and=20 attributes relevant for classification)." Figure 2 illustrates = an=20 example classifier. =20 =20 Based on this conceptual model, [DS-PIB] specifies a classifier = of=20 1:N by N classifier elements. Each classifier element specifies = the=20 following:=20 - element ID which identifies the particular output out of N;=20 - classifier instance ID which identifies the classifier = instance=20 (all the N classifier elements belong to the same classifier = have=20 the same classifier instance ID);=20 - precedence which is an unsigned integer value to represent = the=20 relative order in which classifier elements are applied (the=20 classifier element with the highest precedence will be matched=20 first);=20 - next datapath element which provides a pointer to the next=20 function along this branch out of N fan-out;=20 - filter ID which points to the filter used for this branch = (Note=20 that filter is defined independent of the classifier and used = here=20 as a parameter to the classifier).=20 =20 It is clear from the example above that DiffServ model uses a=20 topological approach to capture the multiple datapath a packet = can=20 potentially take. Graphically, a classifier of 1:N has N output = branches leading to the next N datapath elements. This has=20 significant implication when we consider the interconnected = graph of=20 the functions on FE (see Section 4.3). The alternative is to = use an=20 =20 Yang, et. al. Expires May 2003 [Page 10] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 encoded state approach where each packet gets some state = information=20 associated with it that indicates the datapath it takes next. = For=20 example, using the encoded state approach, a classifier of 1:N = may=20 be represented by just one output branch, if all N of the next=20 datapath elements are of the same block function, say, shaper. = =20 +----------------+=20 | Meter-A |=20 | |=20 ----->| In -|-----PM-1--->=20 | |=20 | Out -|-----PM-2--->=20 +----------------+=20 =20 Figure 3: Meter Followed by Two Preamble Markers=20 =20 The QDDIM model uses the alternative encoded state approach so = that=20 information about the treatment that a packet received on an = ingress=20 interface is allowed to be communicated along with the packet = to the=20 egress interface (see [QDDIM] Section 3.8.3). QDDIM model = represents=20 this information transfer in terms of a packet preamble. Figure = 3=20 shows the same example used in [QDDIM] (section 3.8.3) in which = meter results are captured in a packet preamble. = =93PreamberMarker PM- 1 adds to the packet preamble an indication that the packet = exited=20 Meter A as conforming traffic. Similarly, PreambleMarker PM-2 = adds=20 to the preambles of packets that come through it indications = that=20 they exited Meter A as nonconforming traffic. A PreambleMarker=20 appends its information to whatever is already present in a = packet=20 preamble, as opposed to overwriting what is already there.=94 = =93To=20 foster interoperability, the basic format of the information=20 captured by a PreambleMarker is specified.=94 =93Once a meter = result has=20 been stored in a packet preamble, it is available for any = subsequent=20 Classifier to use.=94 =20 =20 Section 4.3 has more discussion on the difference between the=20 topological approach (as used by DiffServ model) and the = encoded=20 state approach (as used by QDDIM). =20 =20 [DS-PIB] also defines a capability model for classifiers by=20 specifying a bit set to indicate the ability to classify based = on IP=20 source address, IP destination address, IP protocol numbers, IP = DSCP=20 field, layer 4 port number for UDP and TCP, and Ipv6 flow ID. = The=20 capability is thus made known by simply setting the bits=20 accordingly. Similar technique is also used to indicate = capabilities=20 of other functions like meters, droppers, etc. =20 =20 =20 Yang, et. al. Expires May 2003 [Page 11] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 While the DiffServ and QDDIM models are not designed with the=20 primary goal of direct machine implementation, we can still use = them=20 as our starting point. =20 =20 Here is a list of QoS functional blocks that should be = supported:=20 . Classifier=20 . Meter=20 . Marker=20 . Dropper=20 . Counter =20 . Queue and Scheduler=20 . Filter=20 . Shaper=20 =20 =20 4.2.2. Generic Filtering Functions=20 =20 The framework PIB ([FRMWK-PIB]) from the IETF RAP (Resource=20 Allocation Protocol) working group defines four groups of PRCs=20 (Provisioning Classes) that are expected to be common to all = clients=20 that provision policy using COPS-PR ([RFC3084]). One of the = four PRC=20 groups is classifier group, which contains the Base Filter = Class and=20 the other extended filters including the IP Filter, the IEEE = 802=20 Filter and the Internal Label Filter. Even if SPPI ([RFC3159]) = is=20 not the final chosen data model for our FE model, it may still = be=20 valuable to use the work done here as a starting point for the=20 generic filter functions modeling.=20 =20 4.2.3. Vendor Specific Functions=20 =20 New and currently unknown FE functionality can be derived = (i.e.,=20 extended) based on the generic FE Block. The name space used to = identify the FE block type must be extensible such that new = logical=20 functions can be defined and added later to accommodate future=20 innovation in forwarding plane, as long as the new functions = are=20 modeled as an FE block. =20 =20 4.2.4. Port Functions=20 =20 Every FE contains a certain number of interfaces (ports), = including=20 both the inter-NE interfaces and intra-NE interfaces. The = inter-NE=20 interfaces are the external interfaces for the NE to = receive/forward=20 packets from/to the external world. The intra-NE interfaces are = used=20 for FE-FE or FE-CE communications. =20 =20 Certain types of physical ports have sub-interfaces (frame = relay=20 DLCIs, ATM VCs, Ethernet VLans, etc.) as virtual or logical=20 interfaces. Some implementations treat tunnels (e.g., GRE, = L2TP,=20 IPSec, MPLS, etc.) as interfaces, while others do not. = [FORCES-REQ]=20 treats tunneling as high-touch functions and so FE model does = not=20 model tunneling as part of the port functions. Instead, = tunneling is=20 covered in Section 4.2.6. =20 =20 Yang, et. al. Expires May 2003 [Page 12] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 =20 Port function expresses:=20 - the number of ports on the FE;=20 - the sub-interfaces if any;=20 - the static attributes of each port (e.g., port type, = direction,=20 link speed);=20 - the configurable attributes of each port (e.g., IP address,=20 administrative status);=20 - the statistics collected on each port (e.g., number of = packets=20 received); =20 - the current status (up or down).=20 =20 =20 4.2.5. Forwarding Functions=20 =20 Support for IPv4 and IPv6 unicast and multicast forwarding = functions=20 must be provided by the model. =20 =20 Typically, the control plane maintains the Routing Information = Base=20 (RIB), which contains all the routes discovered by all the = routing=20 protocols with all kinds of attributes relevant to the routes. = The=20 forwarding plane uses a different database, the Forwarding=20 Information Base (FIB), which contains only the active subset = of=20 those routes (only the best routes chosen for forwarding) with=20 attributes that are only relevant for forwarding. A component = in the=20 control plane, termed Route Table Manager (RTM), is responsible = to=20 manage the RIB in the CE and maintain the FIB used by the FEs.=20 Therefore, the most important aspect in modeling the forwarding = functions is the data model for the FIB. The model also needs = to=20 support the possibility of multiple paths. =20 =20 At the very minimum, each route in the FIB needs to contain the = following layer-3 information:=20 - the prefix of the destination IP address;=20 - the length of the prefix;=20 - the number of equal-cost multi-path;=20 - the next hop IP address and the egress interface for each = path.=20 =20 Another aspect of the forwarding functions is the method to = resolve=20 a next hop destination IP address into the associated media = address.=20 There are many ways to resolve Layer 3 to Layer 2 address = mapping=20 depending upon link layer. For example, in case of Ethernet = links,=20 the Address Resolution Protocol (ARP, defined in RFC 826) is = used=20 for IPv4 address resolution.=20 =20 Assuming a separate table is maintained in the FEs for address=20 resolution, the following information is necessary for each = address=20 resolution entry:=20 - the next hop IP address;=20 - the media address.=20 =20 Different implementation may have different ways to maintain = the FIB=20 and the resolution table. For example, a FIB may consist of two = =20 Yang, et. al. Expires May 2003 [Page 13] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 separate tables, one to match the prefix to the next hop and = the=20 other to match the next hop to the egress interface. Another=20 implementation may use one table instead. Our model of the=20 forwarding functions should allow such flexibility. =20 =20 4.2.6. High-Touch Functions=20 =20 High-touch functions are those that take action on the contents = or=20 headers of a packet based on content other than what is found = in the=20 IP header. Examples of such functions include NAT, ALG, = firewall,=20 tunneling and L7 content recognition. =20 =20 The ForCES working group first needs to agree upon a small set = of=20 common high-touch functions with well-defined behavior to be=20 included in the initial FE block library. Here is a list of=20 candidate blocks:=20 . NAT=20 . Firewall=20 . Encapsulator=20 . Decapsulator=20 =20 4.2.7. Security Functions=20 =20 The FE model must be able to describe the types of encryption = and/or=20 decryption functions that an FE supports and the associated=20 attributes for such functions.=20 =20 IP Security Policy (IPSP) Working Group in the IETF has started = work=20 in defining the IPSec Policy Information Base [IPSEC-PIB]. = Further=20 study on this is needed to determine whether it can be reused = here=20 and any other additional work is needed.=20 =20 4.2.8. Off-loaded Functions=20 =20 In addition to the packet processing functions that are typical = to=20 find on the FEs, some logical functions may also be executed=20 asynchronously by some FEs, according to a certain finite-state = machine, triggered not only by packet events, but by timer = events as=20 well. Examples of such functions include finite-state machine=20 execution required by TCP termination or OSPF Hello processing = off- loaded from the CE. The FE model must be capable of expressing = these=20 asynchronous functions, so that the CE may take advantage of = such=20 off-loaded functions on the FEs.=20 =20 The ForCES working group first needs to agree upon a small set = of=20 such off-loaded functions with well-understood behavior and=20 interactions with the control plane. =20 =20 4.3. FE Stage and Directed Graph of FE =20 =20 With a set of basic FE functions defined in the block library, = we=20 are ready to model any FE=92s packet processing behavior by a=20 directional graph where each node is an instance of an FE = block,=20 =20 Yang, et. al. Expires May 2003 [Page 14] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 representing a processing stage in the packet datapath. This = section=20 describes the details behind such a =93directed graph=94 FE = model. Such=20 graph represents the FE topology.=20 =20 4.3.1. Basic Concepts=20 =20 An FE stage is simply an instance of an FE block within an FE's = datapath. As a packet flows through an FE along a datapath, it = flows=20 through one or multiple distinct stages, with each stage=20 instantiating a certain FE logical function. Each FE allocates = an=20 FE-unique stage ID to each of its stages and passes the stage = ID=20 along with the corresponding block type as part of the FE stage = information. This allows multiple instances of the same block=20 present in a FE's datapath. Using NAT as an example, one NAT=20 function is typically performed before the forwarding stage = (packets=20 arriving externally have their public addresses replaced with=20 private addresses) and one NAT function is performed after (for = packets exiting the domain, their private addresses are = replaced by=20 public ones). So there are three stages (NAT, forwarding, and = NAT=20 again) in this example datapath, with two NAT instances present = in=20 two different stages. =20 =20 A static FE can be modeled by a directed graph interconnecting = all=20 the stages present in the FE. Each node in the graph = corresponds to=20 a stage. In order to represent the directed interconnection = between=20 two consecutive stages along a datapath, each stage contains a = =93next=20 stage=94 pointer that is simply the stage ID of its next stage = in the=20 graph. Therefore, the following defines an FE stage (i.e., a = node in=20 the FE gragh):=20 - stage identifier which uniquely identifies the node within = this FE=20 graph;=20 - block type which identifies the block function that this = stage is=20 an instance of;=20 - number of downstream stages which corresponds to the number = of=20 downstream nodes connected to this stage;=20 - downstream stage identifiers which corresponds to the set of=20 downstream nodes connected to this stage.=20 =20 With such information defined for each FE stage, it is now = possible=20 for CE to query the state of the static FE graph by querying = for the=20 initial (ingress) stages of the graph and then traversing the = whole=20 graph in a node-by-node fashion. =20 =20 4.3.2. Topological versus Encoded State Approaches=20 =20 As pointed out in Section 4.2.1, there are potentially two = different=20 approaches to model the nodes and the connections between the = nodes=20 in the FE graph, namely, the topological approach and the = encoded=20 state approach. =20 =20 =20 +------------+ +------------+ +------------+=20 input | Ethernet | | | | Ethernet = |output=20 =20 Yang, et. al. Expires May 2003 [Page 15] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 ------->| Ingress |-->| IPv4 L3 LPM|-->| Egress = |----->=20 | Port Mgr | | Forwarder | | Port Mgr |=20 +------------+ +------------+ +------------+=20 =20 {stage ID=3D1, {stage ID=3D2, {stage = ID=3D3,=20 type=3D type=3D type=3D=20 Enet-IngP-Mgr, IPv4-L3-LPM-fwd, = Enet-EgP-Mgr,=20 #downstream=3D1, #downstream=3D1, = #downstream=3D1,=20 downstream=3D{2} downstream=3D{3} = downstream=3Dnone=20 } } }=20 =20 Figure 4. A simple example of an FE graph using encoded = state=20 approach.=20 =20 =20 Input +------------+ +------------+ = output=20 ------->|Ingr-Port #1|-->| |=20 +------------+ | | +------------+=20 ------->|Ingr-Port #2|-->| = |-->|EgressPort#1|----->=20 +------------+ | | +------------+=20 ------->|Ingr-Port #3|-->|IPv4 L3 LPM = |-->|EgressPort#2|----->=20 +------------+ |Forwarder | +------------+=20 ------->|Ingr-Port #4|-->| = |-->|EgressPort#3|----->=20 +------------+ | | +------------+=20 ------->|Ingr-Port #5|-->| = |-->|EgressPort#4|----->=20 +------------+ | | +------------+=20 ------->|Ingr-Port #6|-->| |=20 +------------+ +------------+ =20 =20 {stage ID=3D1 {stage ID=3D7, {stage = ID=3D8,=20 type=3D type=3D type=3D=20 Enet-Ing-port, IPv4-L3-LPM-fwd, = Enet-Eg-port,=20 #downstream=3D1, #downstream=3D4, = #downstream=3D1,=20 downstream=3D{7} downstream=3D = downstream=3Dnone=20 } {8,9,10,11} }=20 . . . } . . .=20 {stage ID=3D6 {stage = ID=3D11,=20 type=3D type=3D=20 Enet-Ing-port, = Enet-Eg-port-Mgr,=20 #downstream=3D1, = #downstream=3D1,=20 downstream=3D{7} = downstream=3Dnone=20 } }=20 =20 Figure 5. The same example as in Figure 4 using = topological=20 approach.=20 =20 Using the topological approach as exemplified by DiffServ = model,=20 there are N connections between a fan-out node of 1:N (e.g., a=20 classifier) and its next stages. Using the encoded state = approach,=20 fewer connections are typically needed between the same fan-out = node=20 and its next stages, because each packet carries some state=20 information as metadata that the next stage nodes can interpret = and=20 invoke different packet treatment. Pure topological approaches = can=20 =20 Yang, et. al. Expires May 2003 [Page 16] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 be overly complex to represent because they force on to build=20 elaborate topologies with a lot more connections. An encoded = state=20 approach is nicer in that it allows one to simplify the graph = and=20 represent the functional blocks with more clarity. But it does=20 require extra metadata to be carried along with the packet, = like the=20 preamble in the QDDIM model.=20 =20 For example in Figure 4, stage #2 (IPv4 L3 LPM Forwarder) = generates=20 some metadata at its output to carry information on which port = the=20 packets should go to, and #3 (Enet-Egress-port-Manager) uses = this=20 meta data to direct the packets to the right egress port. = Figure 5=20 shows how the FE graph looks like when using the pure = topological=20 approach instead, assuming 6 ingress and 4 egress ports. It is = clear=20 that Figure 5 is unwieldy compared to Figure 4.=20 =20 Queue1=20 +---+ +--+=20 | A|------------------->| |--+=20 +->| | | | |=20 | | B|--+ +--+ +--+ +--+ |=20 | +---+ | | | | | |=20 | Meter1 +->| |-->| | |=20 | | | | | |=20 | +--+ +--+ |=20 | Counter1 Absolute Queue2| +--+=20 +---+ | Dropper1 +--+ +--->|A |=20 | A|---+ | |------>|B |=20 -------->| B|------------------------------>| | +--->|C = |------>=20 | C|---+ +--+ | +->|D |=20 | X|-+ | | | +--+=20 +---+ | | +---+ +---+ Queue3| | = Scheduler=20 Classifier1 | | | A|------------>|A | +--+ | |=20 | +->| | | |->| |--+ |=20 | | B|--+ +--+ +->|B | | | |=20 | +---+ | | | | +---+ +--+ |=20 | Meter2 +->| |-+ Mux1 |=20 | | | |=20 | +--+ Queue4 |=20 | Marker1 +--+ |=20 +---------------------------->| |----+ =20 | |=20 +--+=20 =20 Figure 6. An FE example with multiple datapath.=20 =20 Note that the FE graph can represent largely arbitrary = topologies of=20 the stages, regardless which approach (topological or encoded = state)=20 is taken. For example, Figure 6 shows an FE implementing QoS=20 functions via a combination of logical functions like = classifier,=20 meter, marker, queue, scheduler, etc. Both approaches are able = to=20 represent such an FE graph. The only restrictions on topology = relate=20 to the source and sink nature of ingress and egress port = functions=20 respectively. For example, egress port functions must not have = any=20 =20 Yang, et. al. Expires May 2003 [Page 17] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 downstream stages whereas no other stage may refer to an = ingress=20 port function as one of its downstream stages. =20 =20 4.3.3. Cascading FE Blocks=20 =20 An FE block may contain zero, one or more ingress port stages.=20 Similarly, an FE block may contain zero, one or more egress = port=20 stages. In another word, not every FE block has to contain any=20 ingress port or egress port stages. For example, Figure 7 shows = two=20 cascading FE blocks. Block #1 contains one ingress port = function but=20 no egress port function, while block #2 contains one egress = port=20 function but no ingress port function. It is possible to = connect=20 these two FE blocks together to achieve the complete = ingress-to- egress packet processing function. This provides the = flexibility to=20 spread the functions across multiple FEs and interconnect them=20 together later for certain applications. =20 =20 -------------------------------------------------------=20 | +---------+ +------------+ +---------+ |=20 input| | | | | | output |=20 ---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+ = | | port | |Decompressor| |Forwarder| FE | | = | +---------+ +------------+ +---------+ Block #1| | = ------------------------------------------------------| V = | = +-----------------------<-----------------------------+ = | =20 | |-----------------------------------------=20 V | +------------+ +----------+ |=20 | input | | | | output | = =20 +->--+->|Header |-->| Egress |---------+-->=20 | |Compressor | | port | FE |=20 | +------------+ +----------+ Block #2|=20 -----------------------------------------|=20 =20 =20 Figure 7. An example of two different FE blocks connected = together.=20 =20 5. Data Modeling and Representation=20 =20 A formal data modeling language is needed to represent the=20 conceptual FE model described in this document and a full=20 specification will be written using such a data modeling = language.=20 It is also necessary to identify a data representation method = for=20 over-the-wire transport of the FE model data. =20 =20 The following is a list of some potential candidates for=20 consideration. For the moment, we intend to leave this as an = open=20 issue and much debate is needed in the ForCES WG before a = decision=20 can be made. Therefore, we only provide the candidate list and = some=20 initial discussion here without drawing a conclusion yet. =20 =20 - XML (Extensible Markup Language) Schema=20 =20 Yang, et. al. Expires May 2003 [Page 18] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 - ASN.1 (Abstract Syntax Notation One)=20 - SMI (Structure of Management Information) [RFC1155]=20 - SPPI (Structure of Policy Provisioning Information) [RFC3159] = - UML (Universal Modeling Language)=20 =20 Most of the candidates here, with the notable exception of UML, = are=20 capable of representing the model in the document and = over-the-wire.=20 Of course, it is also possible to choose one data model = language for=20 specification in the document and later allow several = over-the-wire=20 representations to map the model into different = implementations. =20 =20 XML has the advantage of being human and machine readable with=20 widely available tools support. However, it is very verbose and = hence less efficient for over-the-wire transport. It also = requires=20 XML parsing functions in both the CE and FE and hence may = impose=20 large footprint esp. for FEs. Currently XML is not yet widely=20 deployed and used in network elements. XML for network = configuration=20 in general remains an open area that still requires substantial = investigation and experiment in IETF. =20 =20 ASN.1 format is human readable and widely used in network = protocols.=20 SMI is based on a subset of ASN.1 and used to define Management = Information Base (MIB) for SNMP. SPPI is the adapted subset of = SMI=20 used to define Policy Information Base (PIB) for COPS. = Substantial=20 investment has been made in SMI/MIBs/SNMP by IETF and the = Internet=20 community collectively has had many years of design and = operation=20 experience with SMI/MIBs/SNMP. However, it is also well = recognized=20 that SMI/MIBs/SNMP is not well suited for configuration and so=20 SPPI/PIBs/COPS-PR attempts to optimize for network provisioning = and=20 configuration. =20 =20 UML is the software industry=92s standard language for = specifying,=20 visualizing, constructing and documenting the artifacts of = software=20 systems. It is a powerful tool for data modeling. However, it = does=20 not provide a data representation format for over-the-wire=20 transport. =20 =20 6. Security Considerations=20 =20 The FE model just describes the representation and organization = of=20 data sets and attributes in the forwarding plane. The = associated=20 communication protocol (i.e., ForCES protocol) will be defined = in=20 separate documents and so the security issues will be addressed = there.=20 =20 7. Intellectual Property Right=20 =20 The authors are not aware of any intellectual property right = issues=20 pertaining to this document.=20 =20 8. IANA consideration=20 =20 =20 Yang, et. al. Expires May 2003 [Page 19] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 A namespace is needed to uniquely identify the FE block type = for=20 each FE logical function. =20 =20 9. Normative References=20 =20 [RFC1812] F. Baker, =93Requirements for IP Version 4 Routers", = June=20 1995.=20 =20 [RFC1155] M. Rose, et. al., =93Structure and Identification of=20 Management Informationfor TCP/IP-based Internets", = May=20 1990.=20 =20 [RFC3084] K. Chan, et. al., =93COPS Usage for Policy = Provisioning,=94=20 March 2001.=20 =20 [RFC3159] K. McCloghrie, et. al., =93Structure of Policy = Provisioning=20 Information (SPPI)", August 2001.=20 =20 [RFC3290] Y. Bernet, et. al., =93An Informal Management Model = for=20 Diffserv Routers=94, May 2002.=20 =20 10. Informative References=20 =20 [FORCES-REQ] H. Khosravi, et. al., =93Requirements for = Separation of=20 IP Control and Forwarding", work in progress, Oct = 2002,=20 .=20 =20 [DS-PIB] M. Fine, et. al., =93Differentiated Services Quality = of=20 Service Policy Information Base=94, work in = progress, June=20 2002, .=20 =20 [FRMWK-PIB] R.Sahita, et. al., =93Framework Policy Information = Base=94,=20 RFC 3318, March 2003.=20 =20 [QDDIM] B. Moore, et. al., =93Information Model for Describing = Network=20 Device QoS Datapath Mechanisms=94, work in progress, = May=20 2002, = .=20 =20 [QPIM] Y. Snir, et. al., =93Policy Framework QoS Information = Model=94,=20 work in progress, Nov 2001, = =20 =20 =20 Yang, et. al. Expires May 2003 [Page 20] = =0C Internet Draft ForCES FE Functional Model Nov = 2002=20 =20 =20 [IPSEC-MIB] C. Madson, et. al., =93IPsec Flow Monitoring = MIB=94, work in=20 progress, March 2003, = =20 =20 =20 11. Acknowledgments=20 =20 The authors would also like to thank the following individuals = for=20 their invaluable technical input: David Putzolu, Hormuzd = Khosravi,=20 Eric Johnson, David Durham, Andrzej Matejko, T. Sridhar.=20 =20 12. Authors' Addresses=20 =20 Lily L. Yang=20 Intel Labs=20 2111 NE 25th Avenue=20 Hillsboro, OR 97124 USA=20 Phone: +1 503 264 8813=20 Email: lily.l.yang@intel.com=20 =20 Joel Halpern=20 P.O.Box 6049=20 Leesburg, VA 20178=20 Phone: +1 703 371 3043=20 Email: jmh@joelhalpern.com=20 =20 Ram Gopal=20 Nokia Research Center=20 5, Wayside Road,=20 Burlington, MA 01803=20 Phone: +1 781 993 3685=20 Email: ram.gopal@nokia.com=20 =20 Ram Dantu=20 Department of Computer Science,=20 University of North Texas,=20 Denton, Texas, 76203=20 tele: 940 565 2822=20 Email: rdantu@unt.edu=20 =20 =20 =20 Yang, et. al. Expires May 2003 [Page 21] = =0C ------_=_NextPart_000_01C2E8FC.9B500330-- 2003 Message-Id: Date: Mon, 10 Mar 2003 14:18:08 +0100 From: Patrick Droz Organization: IBM Research Subject: Tentative Agenda Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Attached is the tentative agenda for the upcoming meeting. I had to shorten all of the presentations in order to fit them into our 1 h slot. Please let me know if this fits everybody. Thanks, Patrick Forwarding and Control Element Separation (ForCES) Tuesday March 18th 2003 at 14:15 - 15:15 ======================================== CHAIRS: David Putzolu Patrick Droz ADs: Bill Fenner Alex Zinin AGENDA: 20 min - ForwArding and Control ElemenT protocol (FACT) draft-gopal-forces-fact-03.txt Alex / Ram 20 min - Netlink2 as ForCES protocol draft-jhsrha-forces-netlink2-00.txt Robert / Jamal 20 min - ForCES Forwarding Element Functional Model draft-yang-forces-model-01.txt Ram -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 2003 Message-Id: Date: Fri, 7 Mar 2003 06:50:45 -0500 Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-gopal-forces-fact-03.txt Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ForwArding and Control ElemenT protocol (FACT) Author(s) : A. Audu, R. Gopal et al. Filename : draft-gopal-forces-fact-03.txt Pages : 53 Date : 2003-3-6 This document defines a FACT protocol that is suitable for communicating between Forwarding Element and Control Elements inside a network element. This protocol addresses all the requirements described in Forces [3] requirements document. This document also describes the architecture that FACT may leverage during the protocol operation A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gopal-forces-fact-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gopal-forces-fact-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-gopal-forces-fact-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6124527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gopal-forces-fact-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-gopal-forces-fact-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6124527.I-D@ietf.org> --OtherAccess-- --NextPart--