Subject: newer framework-03 draft

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 18 Oct 2002 13:13:10 -0700

Hi, all

Here is another rev of the framework draft, incorporating comments from
Jamal and Robert.
Change summary:
1) Per comments from Jamal, in Section 3.2, regarding redundancy support in
Fig 5., the paragraph is revised as:
        For example, in Figure 5, FE1 and FE2 can be configured to accept
commands from both the primary CE (CE1) and the backup CE (CE2). Upon
detection of CE1 failure, perhaps across the Fr reference point, CE2 is
configured to take over activities of CE1. This is beyond the scope of
ForCES and is not discussed further.
2) Per comments from Robert, in Section 5 "Applicability to RFC1812", a new
paragraph is added to address the general issue of off-loaded functions.
        In general, the forwarding plane carries out the bulk of the
per-packet processing that is required at line speed, while the control
plane carries most of the computationally complex operations that are
typical of the control and signaling protocols. However, it is not practical
to draw a rigid line to divide the processing into CEs and FEs cleanly. Nor
should the ForCES architecture limits the innovative approaches in control
and forwarding plane separation. As more and more processing power is
available in the FEs, some of the control functions that traditionally are
performed by CEs may now be moved to FEs for better performance and
scalability. Such offloaded functions may include part of ICMP or TCP
processing, or part of routing protocols. Once off-loaded onto the
forwarding plane, such CE functions, even though logically belong to the
control plane, now become part of the FE logical functions. Just like the
other logical functions performed by FEs, such off-loaded functions must be
expressed as part of the FE model so that the CEs can decide how to best
take advantage of these off-loaded functions when present on the FEs.
Then in sub-section 5.6 "Application Protocols -- Routing Protocols", a more
specific paragraph is devoted to off-loaded functions in routing, like OSPF
Hello example.
        For performance or scalability reasons, portions of the control
plane functions that need faster response may be moved from the CEs and
off-loaded onto the FEs. For example in OSPF, the Hello protocol packets are
generated and processed periodically. When done at CEs, the inbound Hello
packets have to traverse from the external interfaces at the FEs to the CEs
via the internal CE-FE channel. Similarly, the outbound Hello packets have
to go from the CEs to the FEs and to the external interfaces. Frequent Hello
updates place heavy processing overhead on the CEs and can overwhelm the
CE-FE channel as well. Since typically there are far more FEs than CEs in a
router, when off-loaded, the Hello packets are processed in a much more
distributed and scalable fashion. Interoperability is ensured by expressing
such off-loaded functions in the FE model.

Please check out the draft and provide comments. We would like to submit the
draft officially sometime next week.

Thanks,
Lily

 <<draft-ietf-forces-framework-03.txt>>
 <<draft-ietf-forces-framework-03.txt>>