1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
|
<pre>Internet Engineering Task Force (IETF) A. Crouch
Request for Comments: 6041 H. Khosravi
Category: Informational Intel
ISSN: 2070-1721 A. Doria, Ed.
LTU
X. Wang
Huawei
K. Ogawa
NTT Corporation
October 2010
<span class="h1">Forwarding and Control Element Separation (ForCES)</span>
<span class="h1">Applicability Statement</span>
Abstract
The Forwarding and Control Element Separation (ForCES) protocol
defines a standard framework and mechanism for the interconnection
between control elements and forwarding elements in IP routers and
similar devices. In this document we describe the applicability of
the ForCES model and protocol. We provide example deployment
scenarios and functionality, as well as document applications that
would be inappropriate for ForCES.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6041">http://www.rfc-editor.org/info/rfc6041</a>.
<span class="grey">Crouch, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">Crouch, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Purpose .........................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Terminology .....................................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Applicability to IP Networks ....................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Applicable Services ........................................<a href="#page-5">5</a>
4.1.1. Association, Capability Discovery, and
Information Exchange ................................<a href="#page-5">5</a>
<a href="#section-4.1.2">4.1.2</a>. Topology Information Exchange .......................<a href="#page-6">6</a>
<a href="#section-4.1.3">4.1.3</a>. Configuration .......................................<a href="#page-6">6</a>
<a href="#section-4.1.4">4.1.4</a>. Routing Exchange ....................................<a href="#page-6">6</a>
<a href="#section-4.1.5">4.1.5</a>. QoS Capabilities Exchange and Configuration .........<a href="#page-7">7</a>
<a href="#section-4.1.6">4.1.6</a>. Security Exchange ...................................<a href="#page-7">7</a>
<a href="#section-4.1.7">4.1.7</a>. Filtering Exchange and Firewalls ....................<a href="#page-7">7</a>
<a href="#section-4.1.8">4.1.8</a>. Encapsulation/Tunneling Exchange ....................<a href="#page-7">7</a>
<a href="#section-4.1.9">4.1.9</a>. NAT and Application-Level Gateways ..................<a href="#page-7">7</a>
<a href="#section-4.1.10">4.1.10</a>. Measurement and Accounting .........................<a href="#page-7">7</a>
<a href="#section-4.1.11">4.1.11</a>. Diagnostics ........................................<a href="#page-8">8</a>
<a href="#section-4.1.12">4.1.12</a>. Redundancy and Failover ............................<a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. CE-FE Link Capability ......................................<a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. CE/FE Locality .............................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-9">9</a>
<a href="#section-6">6</a>. ForCES Manageability ............................................<a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. The NE as an Atomic Element ...............................<a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. The NE as Composed of Manageable Elements .................<a href="#page-10">10</a>
<a href="#section-6.3">6.3</a>. ForCES Protocol MIB .......................................<a href="#page-10">10</a>
<a href="#section-6.3.1">6.3.1</a>. MIB Management of an FE ............................<a href="#page-11">11</a>
<a href="#section-6.4">6.4</a>. The FEM and CEM ...........................................<a href="#page-12">12</a>
<a href="#section-7">7</a>. Contributors ...................................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. Acknowledgments ................................................<a href="#page-12">12</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-12">12</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-12">12</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Forwarding and Control Element Separation (ForCES) protocol
defines a standard framework and mechanism for the exchange of
information between the logically separate functionality of the
control and data forwarding planes of IP routers and similar devices.
It focuses on the communication necessary for separation of control
plane functionality such as routing protocols, signaling protocols,
and admission control from data forwarding plane per-packet
activities such as packet forwarding, queuing, and header editing.
<span class="grey">Crouch, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
This document defines the applicability of the ForCES mechanisms. It
describes types of configurations and settings where ForCES is most
appropriately applied. This document also describes scenarios and
configurations where ForCES would not be appropriate for use.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Purpose</span>
The purpose of the ForCES Applicability Statement is to capture the
intent of the ForCES protocol [<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>] designers as to how the
protocol could be used in conjunction with the ForCES model [<a href="./rfc5812" title=""Forwarding and Control Element Separation (ForCES) Forwarding Element Model"">RFC5812</a>]
and a Transport Mapping Layer [<a href="./rfc5811" title=""SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol"">RFC5811</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
A set of concepts associated with ForCES was introduced in
"Requirements for Separation of IP Control and Forwarding" [<a href="./rfc3654" title=""Requirements for Separation of IP Control and Forwarding"">RFC3654</a>]
and in "Forwarding and Control Element Separation (ForCES) Framework"
[<a href="./rfc3746" title=""Forwarding and Control Element Separation (ForCES) Framework"">RFC3746</a>]. The terminology associated with these concepts and with
the protocol elements in ForCES is defined in the "Forwarding and
Control Element Separation (ForCES) Protocol Specification"
[<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>].
The reader is directed to these documents for the conceptual
introduction and for definitions, including the following acronyms:
o CE: control element
o CEM: CE Manager
o FE: forwarding element
o FEM: FE Manager
o ForCES: Forwarding and Control Element Separation protocol
o LFB: Logical Function Block
o NE: ForCES network element
o TML: Transport Mapping Layer
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Applicability to IP Networks</span>
This section lists the areas of ForCES applicability in IP network
devices. Some relatively low-end routing systems may be implemented
on simple hardware that performs both control and packet forwarding
functionality. ForCES may not be useful for such devices.
<span class="grey">Crouch, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
Higher-end routing systems typically distribute work amongst several
interface-processing elements, and these devices (FEs) therefore need
to communicate with the control element(s) to perform their job. A
higher-end router may also distribute control processing amongst
several processing elements (CEs). ForCES provides a standard way to
do this communication. ForCES also provides support for high-
availability configurations that include a primary CE and one or more
secondary CEs.
The remainder of this section lists the applicable services that
ForCES may support, applicable FE functionality, applicable CE-FE
link scenarios, and applicable topologies in which ForCES may be
deployed.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Applicable Services</span>
In this section we describe the applicability of ForCES for the
following control-forwarding-plane services:
o Association, Capability Discovery, and Information Exchange
o Topology Information Exchange
o Configuration
o Routing Exchange
o Quality of Service (QoS) Exchange
o Security Exchange
o Filtering Exchange
o Encapsulation/Tunneling Exchange
o NAT and Application-Level Gateways
o Measurement and Accounting
o Diagnostics
o CE Redundancy or CE Failover
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Association, Capability Discovery, and Information Exchange</span>
Association is the first step of the ForCES protocol exchange in
which capability discovery and exchange happens between one or more
CEs and the FEs. ForCES assumes that CEs and FEs already have
<span class="grey">Crouch, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
sufficient information to begin communication in a secure manner.
The ForCES protocol is only applicable after CEs and FEs have
discovered each other. ForCES makes no assumption about whether
discovery was performed using a dynamic protocol or merely static
configuration. Some discussion about how this can occur can be found
in <a href="#section-6.4">Section 6.4</a> of this document.
During the association phase, CEs and FEs exchange capability
information with each other. For example, the FEs express the number
of interface ports they provide, as well as the static and
configurable attributes of each port.
In addition to initial configuration, the CEs and FEs also exchange
dynamic configuration changes using ForCES. For example, FEs
asynchronously inform the CEs of an increase/decrease in available
resources or capabilities on the FE.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Topology Information Exchange</span>
In this context, topology information relates to how the FEs are
interconnected with each other with respect to packet forwarding.
Topology discovery is outside the scope of the ForCES protocol. An
implementation can choose its own method of topology discovery (for
example, it can use a standard topology discovery protocol or apply a
static topology configuration policy). Once the topology is
established, the ForCES protocol may be used to transmit the
resulting information to the CEs.
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Configuration</span>
ForCES is used to perform FE configuration. For example, CEs set
configurable FE attributes such as IP addresses, etc. for their
interfaces.
<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>. Routing Exchange</span>
ForCES may be used to deliver packet forwarding information resulting
from CE routing calculations. For example, CEs may send forwarding
table updates to the FEs, so that they can make forwarding decisions.
FEs may inform the CEs in the event of a forwarding table miss.
ForCES may also be used to configure Equal Cost Multi-Path (ECMP)
capability.
<span class="grey">Crouch, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
<span class="h4"><a class="selflink" id="section-4.1.5" href="#section-4.1.5">4.1.5</a>. QoS Capabilities Exchange and Configuration</span>
ForCES may be used to exchange QoS capabilities between CEs and FEs.
For example, an FE may express QoS capabilities to the CE. Such
capabilities might include metering, policing, shaping, and queuing
functions. The CE may use ForCES to configure these capabilities.
<span class="h4"><a class="selflink" id="section-4.1.6" href="#section-4.1.6">4.1.6</a>. Security Exchange</span>
ForCES may be used to exchange security information between a CE and
the FEs it controls. For example, the FE may use ForCES to express
the types of encryption that it is capable of using in an IP Security
(IPsec) tunnel. The CE may use ForCES to configure such a tunnel.
The CEs would be responsible for the NE dynamic key exchanges and
updates.
<span class="h4"><a class="selflink" id="section-4.1.7" href="#section-4.1.7">4.1.7</a>. Filtering Exchange and Firewalls</span>
ForCES may be used to exchange filtering information. For example,
FEs may use ForCES to express the filtering functions, such as
classification and action, that they can perform, and the CE may
configure these capabilities.
<span class="h4"><a class="selflink" id="section-4.1.8" href="#section-4.1.8">4.1.8</a>. Encapsulation/Tunneling Exchange</span>
ForCES may be used to exchange encapsulation capabilities of an FE,
such as tunneling, and the configuration of such capabilities.
<span class="h4"><a class="selflink" id="section-4.1.9" href="#section-4.1.9">4.1.9</a>. NAT and Application-Level Gateways</span>
ForCES may be used to exchange configuration information for Network
Address Translators. Whilst ForCES is not specifically designed for
the configuration of application-level gateway functionality, this
may be in scope for some types of application-level gateways.
<span class="h4"><a class="selflink" id="section-4.1.10" href="#section-4.1.10">4.1.10</a>. Measurement and Accounting</span>
ForCES may be used to exchange configuration information regarding
traffic measurement and accounting functionality. In this area,
ForCES may overlap somewhat with functionality provided by network
management mechanisms such as the Simple Network Management Protocol
(SNMP). In some cases, ForCES may be used to convey information to
the CE to be reported externally using SNMP. A further discussion of
this capability is covered in <a href="#section-6">Section 6</a> of this document.
<span class="grey">Crouch, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
<span class="h4"><a class="selflink" id="section-4.1.11" href="#section-4.1.11">4.1.11</a>. Diagnostics</span>
ForCES may be used for CEs and FEs to exchange diagnostic
information. For example, an FE can send self-test results to a CE.
<span class="h4"><a class="selflink" id="section-4.1.12" href="#section-4.1.12">4.1.12</a>. Redundancy and Failover</span>
The ForCES architecture includes mechanisms that allow for multiple
redundant CEs and FEs in a ForCES NE. The ForCES-model LFB
definitions provide sufficient component details via component
identifiers to be universally unique within an NE. The ForCES
protocol includes mechanisms to facilitate transactions as well as
atomicity across the NE.
Given the above, it is possible to deploy redundant CEs and FEs that
incorporate failover.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. CE-FE Link Capability</span>
When using ForCES, the bandwidth of the CE-FE link is a
consideration, and cannot be ignored. For example, sending a full
routing table is reasonable over a high-bandwidth link, but could be
non-trivial over a lower-bandwidth link. ForCES should be
sufficiently future-proof to be applicable in scenarios where routing
tables grow to several orders of magnitude greater than their current
size. However, we also note that not all IP routers need full
routing tables.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. CE/FE Locality</span>
ForCES is intended for environments where one of the following
applies:
o The control interconnect is some form of local bus, switch, or
LAN, where reliability is high, closely controlled, and not
susceptible to external disruption that does not also affect the
CEs and/or FEs.
o The control interconnect shares its fate with the FE's forwarding
function. Typically this is because the control connection is
also the FE's primary packet forwarding connection, and so if that
link goes down, the FE cannot forward packets anyway.
The key guideline is that the reliability of the device should not be
significantly reduced by the separation of control and forwarding
functionality.
<span class="grey">Crouch, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
Taking this into account, ForCES is applicable in the following CE/FE
localities:
Single Box NE:
chassis with multiple CEs and FEs set up. ForCES is applicable in
localities consisting of control and forwarding elements that are
components in the same physical box.
Example: a network element with a single control blade, and one or
more forwarding blades, all present in the same chassis and
sharing an interconnect such as Ethernet or Peripheral Component
Interconnect (PCI). In this locality, the majority of the data
traffic being forwarded typically does not traverse the same links
as the ForCES control traffic.
Multiple Box NE:
separated CE and FE, where physical locality could be the same
rack, room, or building; or long distances that could span across
continents and oceans. ForCES is applicable in localities
consisting of control and forwarding elements that are separated
by a single hop or multiple hops in the network.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The ForCES protocol allows for a variety of security levels
[<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>]. When operating under a secured physical environment, or
for other operational concerns (in some cases, performance issues),
the operator may turn off all the security functions between CEs and
FEs. When the operator makes a decision to secure the path between
the FEs and CEs, then the operator chooses from one of the options
provided by the TML. Security choices provided by the TML take
effect during the pre-association phase of the ForCES protocol. An
operator may choose to use all, some, or none of the security
services provided by the TML in a CE-FE connection. A ForCES NE is
required to provide CE/FE node authentication services, and may
provide message integrity and confidentiality services. The NE may
provide these services by employing IPsec or Transport Layer Security
(TLS), depending on the choice of TML used in the deployment of
the NE.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. ForCES Manageability</span>
From the architectural perspective, the ForCES NE is a single network
element. As an example, if the ForCES NE is specifically a router
that needs to be managed, then it should be managed in essentially
the same way any router should be managed. From another perspective,
element management could directly view the individual entities and
interfaces that make up a ForCES NE. However, any element management
<span class="grey">Crouch, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
updates made directly on these entities and interfaces may compromise
the control relationship between the CEs and the FEs, unless the
update mechanism has been accounted for in the model used by the NE.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. The NE as an Atomic Element</span>
From the ForCES Requirements <a href="./rfc3654#section-4">[RFC3654], Section 4</a>, point 4:
A NE MUST support the appearance of a single functional device.
As a single functional device, a ForCES NE runs protocols, and each
of the protocols has its own existing manageability aspects that are
documented elsewhere. As an example, a router would also have a
configuration interface. When viewed in this manner, the NE is
controlled as a single routing entity, and no new management beyond
what is already available for routers and routing protocols would be
required for a ForCES NE. Management commands on a management
interface to the NE will arrive at the CE and may require ForCES
interactions between the CE and FEs to complete. This may impact the
atomicity of such commands and may require careful implementation by
the CE.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. The NE as Composed of Manageable Elements</span>
When viewed as a decomposed set of elements from the management
perspective, the ForCES NE is divided into a set of one of more
control elements, forwarding elements, and the interfaces between
them. The interface functionality between the CE and the FE is
provided by the ForCES protocol. A MIB module is provided for the
purpose of gaining management information on the operation of the
protocol described in <a href="#section-6.3">Section 6.3</a> of this document.
Additionally, the architecture makes provisions for configuration
control of the individual CEs and FEs. This is handled by elements
called the FE Manager (FEM) and the CE Manager (CEM). Specifically,
from the ForCES Requirements RFC <a href="./rfc3654#section-4">[RFC3654], Section 4</a>, point 4:
However, external entities (e.g., FE Managers and CE Managers) MAY
have direct access to individual ForCES protocol elements for
providing information to transition them from the pre-association
to the post-association phase.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. ForCES Protocol MIB</span>
The ForCES MIB [<a href="./rfc5813" title=""Forwarding and Control Element Separation (ForCES) MIB"">RFC5813</a>] defines a primarily read-only MIB module
that captures information related to the ForCES protocol. This
includes state information about the associations between CE(s) and
FE(s) in the NE.
<span class="grey">Crouch, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
The ForCES MIB does not include information that is specified in
other MIB modules, such as packet counters for interfaces, etc.
More specifically, the information in the ForCES MIB module relative
to associations includes:
o identifiers of the elements in the association
o state of the association
o configuration parameters of the association
o statistics of the association
<span class="h4"><a class="selflink" id="section-6.3.1" href="#section-6.3.1">6.3.1</a>. MIB Management of an FE</span>
While it is possible to manage an FE from an element manager, several
requirements relating to this have been included in the ForCES
Requirements.
From the ForCES Requirements <a href="./rfc3654#section-4">[RFC3654], Section 4</a>, point 14:
1. The ability for a management tool (e.g., SNMP) to be used to
read (but not change) the state of FE SHOULD NOT be precluded.
2. It MUST NOT be possible for management tools (e.g., SNMP, etc)
to change the state of a FE in a manner that affects overall NE
behavior without the CE being notified.
The ForCES Framework <a href="./rfc3746#section-5.7">[RFC3746], Section 5.7</a>, goes further in
discussing the manner in which FEs should handle management requests
that are specifically directed to the FE:
(For a ForCES NE that is an IP router,) <a href="./rfc1812">RFC 1812</a> [<a href="./rfc1812" title=""Requirements for IP Version 4 Routers"">RFC1812</a>] also
dictates that "Routers must be manageable by SNMP". In general,
for the post-association phase, most external management tasks
(including SNMP) should be done through interaction with the CE in
order to support the appearance of a single functional device.
Therefore, it is recommended that an SNMP agent be implemented by
CEs and that the SNMP messages received by FEs be redirected to
their CEs. AgentX framework defined in <a href="./rfc2741">RFC 2741</a> [<a href="./rfc2741" title=""Agent Extensibility (AgentX) Protocol Version 1"">RFC2741</a>]) may be
applied here such that CEs act in the role of master agent to
process SNMP messages while FEs act in the role of subagent to
provide access to the MIB objects residing on FEs. AgentX
protocol messages between the master agent (CE) and the subagent
(FE) are encapsulated and transported via ForCES, just like data
packets from any other application layer protocols.
<span class="grey">Crouch, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. The FEM and CEM</span>
Though out of scope for the initial ForCES specification effort, the
ForCES architecture includes two entities: the CE Manager (CEM) and
the FE Manager (FEM). From the ForCES Protocol Specification
[<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>]:
CE Manager (CEM):
A logical entity responsible for generic CE management tasks. It
is particularly used during the pre-association phase to determine
with which FE(s) a CE should communicate.
FE Manager (FEM):
A logical entity responsible for generic FE management tasks. It
is used during the pre-association phase to determine with which
CE(s) an FE should communicate.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Contributors</span>
Mark Handley was an initial author involved in the earlier versions
of this document.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
Many of the participants in the ForCES WG, as well as fellow
employees of the authors, have provided valuable input into this
work. Particular thanks go to Jamal Hadi Salim, our WG chair and
document shepherd; and to Adrian Farrel, the AD for the area; for
their review, comments, and encouragement, without which this
document might never have been completed.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC1812">RFC1812</a>] Baker, F., "Requirements for IP Version 4 Routers",
<a href="./rfc1812">RFC 1812</a>, June 1995.
[<a id="ref-RFC5810">RFC5810</a>] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol
Specification", <a href="./rfc5810">RFC 5810</a>, March 2010.
[<a id="ref-RFC5811">RFC5811</a>] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport
Mapping Layer (TML) for the Forwarding and Control
Element Separation (ForCES) Protocol", <a href="./rfc5811">RFC 5811</a>,
March 2010.
<span class="grey">Crouch, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
[<a id="ref-RFC5812">RFC5812</a>] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model",
<a href="./rfc5812">RFC 5812</a>, March 2010.
[<a id="ref-RFC5813">RFC5813</a>] Haas, R., "Forwarding and Control Element Separation
(ForCES) MIB", <a href="./rfc5813">RFC 5813</a>, March 2010.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC2741">RFC2741</a>] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco,
"Agent Extensibility (AgentX) Protocol Version 1",
<a href="./rfc2741">RFC 2741</a>, January 2000.
[<a id="ref-RFC3654">RFC3654</a>] Khosravi, H. and T. Anderson, "Requirements for
Separation of IP Control and Forwarding", <a href="./rfc3654">RFC 3654</a>,
November 2003.
[<a id="ref-RFC3746">RFC3746</a>] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", <a href="./rfc3746">RFC 3746</a>, April 2004.
<span class="grey">Crouch, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6041">RFC 6041</a> ForCES Applicability Statement October 2010</span>
Authors' Addresses
Alan Crouch
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
USA
Phone: +1 503 264 2196
EMail: alan.crouch@intel.com
Hormuzd Khosravi
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
USA
Phone: 1-503-264-0334
EMail: hormuzd.m.khosravi@intel.com
Avri Doria (editor)
LTU
Lulea University of Technology
Sweden
Phone: +46 73 277 1788
EMail: avri@acm.org
Xin-ping Wang
Huawei
Beijing
China
Phone: +86 10 82836067
EMail: carly.wang@huawei.com
Kentaro Ogawa
NTT Corporation
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
EMail: ogawa.kentaro@lab.ntt.co.jp
Crouch, et al. Informational [Page 14]
</pre>
|
