forked from dcdolson/draft-dolson-sfc-hierarchical
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-dolson-sfc-hierarchical.xml
executable file
·933 lines (869 loc) · 40.9 KB
/
draft-dolson-sfc-hierarchical.xml
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
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.draft-homma-sfc-forwarding-methods-analysis SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-homma-sfc-forwarding-methods-analysis-01.xml">
<!ENTITY I-D.draft-ietf-sfc-nsh SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-nsh-00.xml">
<!ENTITY I-D.draft-ietf-sfc-architecture SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-architecture-07.xml">
<!ENTITY I-D.draft-ietf-sfc-dc-use-cases SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-dc-use-cases-02.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-dolson-sfc-hierarchical-03" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Hierarchical Service Function Chaining</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="David Dolson" initials="D." surname="Dolson">
<organization>Sandvine</organization>
<address>
<postal>
<street>408 Albert Street</street>
<!-- Reorder these if your country does things differently -->
<city>Waterloo</city>
<region>ON</region>
<code>N2L 3V3</code>
<country>Canada</country>
</postal>
<phone>+1 519 880 2400</phone>
<email>ddolson@sandvine.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Shunsuke Homma" initials="S." surname="Homma">
<organization abbrev="NTT">NTT, Corp.</organization>
<address>
<postal>
<street>3-9-11, Midori-cho</street>
<city>Musashino-shi</city>
<region>Tokyo</region>
<code>180-8585</code>
<country>Japan</country>
</postal>
<email>homma.shunsuke@lab.ntt.co.jp</email>
</address>
</author>
<author fullname="Diego R. Lopez" initials="D. R." surname="Lopez">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz, 82</street>
<city>Madrid</city>
<region></region>
<code>28006</code>
<country>Spain</country>
</postal>
<phone>+34 913 129 041</phone>
<email>diego.r.lopez@telefonica.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange Group</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email> mohamed.boucadair@orange.com </email>
</address>
</author>
<author fullname="Dapeng Liu" initials="D." surname="Liu">
<organization>Alibaba Group</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<code>100022</code>
<country>China</country>
</postal>
<email> max.ldp@alibaba-inc.com </email>
</address>
</author>
<date month="Sep" year="2015" />
<!-- Meta-data Declarations -->
<area>Routing Area</area>
<workgroup>Service Function Chaining</workgroup>
<keyword>sfc</keyword>
<keyword>hierarchical</keyword>
<abstract>
<t>
Hierarchical Service Function Chaining (hSFC) is a network architecture
allowing an organization to compartmentalize a large-scale network into
multiple domains of administration.
</t>
<t>
The goals of hSFC are to make a large-scale network easier to reason
about, simpler to control and to support independent functional groups
within large operators.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Service Function Chaining (SFC) is a technique for prescribing
differentiated traffic forwarding policies within the SFC domain.
SFC is described in detail in the
<xref target="I-D.ietf-sfc-architecture">
SFC architecture document
</xref>,
and is not repeated here.
</t>
<t>
In this document we consider the difficult problem of implementing SFC
across a large, geographically dispersed network comprised of millions
of hosts and thousands of network forwarding elements, involving
multiple operational teams (with varying functional responsibilities).
We expect asymmetrical routing is inherent in the network, while
recognizing that some Service Functions (SFs) require bidirectional
traffic for transport-layer sessions (e.g., NATs, firewalls). We assume
that some paths need to be selected on the basis of application-specific
data visible to the network, with 5-tuple stickiness to specific Service
Function instances.
</t>
<t>
Note: in this document, the notion of the "path" of a packet is the
series of SF instances traversed by a packet. The means of delivering
packets between SFs (the forwarding mechanisms of the underlay network)
is not relevant to the current discussion.
</t>
<t>
Difficult problems are often made easier by decomposing them in a
hierarchical (nested) manner. So instead of considering an omniscient
SFC Control Plane that can manage (create, withdraw, supervise, etc.)
complete paths from one end of the network to the other, we decompose
the network into smaller sub-domains. Each sub-domain may support a
subset of the network applications or a subset of the users. The
criteria for determining decomposition into SFC-enabled sub-domains are
beyond the scope of this document.
</t>
<t>
Note that decomposing a network into multiple SFC-enabled domains should
permit end-to-end visibility of Service Functions and Service Function
Paths. Decomposition should also be implemented with special care to
ease monitoring and troubleshooting of the network as a whole.
</t>
<t>
An example of simplifying a network by using multiple SF domains is
further discussed in <xref target="I-D.ietf-sfc-dc-use-cases"/>.
</t>
<t>
We assume the SF technology uses
<xref target="I-D.ietf-sfc-nsh">NSH</xref> or a similar labeling
mechanism.
</t>
<t>
The "domains" discussed in this document are assumed to be under control
of a single organization, such that here is a strong trust relationship
between the domains. The intention of creating multiple domains is to
improve the ability to operate a network. It is outside of the scope of
the document to consider domains operated by different organizations.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Hierarchical Service Function Chaining (hSFC)">
<t>
A hierarchy has multiple levels. The top-most level encompasses the
entire network domain to be managed, and lower levels encompass
portions of the network.
</t>
<section title="Top Level">
<t>
Considering the example in <xref target="fig_hierarchical_top"/>, a
top-level network domain includes SFC components distributed over a
wide area, including:
<list style="symbols">
<t>classifiers (CFs),</t>
<t>Service Function Forwarders (SFFs) and</t>
<t>Sub-domains.</t>
</list>
For the sake of clarity, components of the underlay network are not
shown; an underlay network is assumed to provide connectivity between
SFC components.
</t>
<t>
Top-level service function paths carry packets from classifiers
through a series of SFFs and sub-domains, with the operations within
sub-domains being opaque to the higher levels.
</t>
<t>
We expect the system to include a top-level control-plane having
responsibility for configuring forwarding and classification.
The top-level Service Chaining control-plane manages end-to-end
service chains and associated service function paths from network edge
points to sub-domains and configuring top-level classifiers at a
coarse level (e.g., based on source or destination host) to forward
traffic along paths that will transit appropriate sub-domains. The
figure shows one possible service chain passing from edge, through two
sub-domains, to network egress. The top-level control plane does NOT
configure classification or forwarding within the sub-domains.
</t>
<t>
At this network-wide level, the number of SFPs required is a linear
function of the number of ways in which a packet is required to
traverse different sub-domains and egress the network. Note that the
various paths which may be taken within a sub-domain are not
represented by distinct network-wide SFPs; specific policies at the
ingress nodes of each sub-domain bind flows to sub-domain paths.
</t>
<t>
Packets are classified at the edge of the network to select the paths
by which sub-domains are to be traversed. At the ingress of each
sub-domain, paths are reclassified to select the paths by which SFs in
the sub-domain are to be traversed. At the egress of each sub-domain,
packets are returned to the top-level paths. Contrast this with an
approach requiring the top-level classifier to select paths to specify
all of the SFs in each sub-domains.
</t>
<t>
It should be assumed that some service functions in the network
require bidirectional symmetry of paths (see more in
<xref target="section_classifier"/>). Therefore the classifiers at the
top level must be configured with policies ensuring server-to-client
packets take the reverse path of client-to-server packet through
sub-domains. (Recall the "path" denotes the series of service
functions; the precise physical network path within the underlay
network is not relevant here.)
</t>
<figure anchor="fig_hierarchical_top"
title="Network-wide view of Top Level of Hierarchy">
<artwork><![CDATA[
+------------+
|Sub-domain#1|
| in DC1 |
+----+-------+
|
.---- SFF1 ------. +--+
+--+ / / | \--|CF|
--->|CF|--/---->' | \ +--+
+--+ / SC#1 | \
| | |
| V .------>|--->
| / / |
\ | / /
+--+ \ | / / +--+
|CF|---\ | / /---|CF|
+--+ '---- SFF2 ------' +--+
|
+----+-------+
|Sub-domain#2|
| in DC2 |
+------------+
]]> </artwork>
<postamble>
One path is shown from edge classifier to SFF1 to Sub-domain#1
(residing in data-center1) to SFF1 to SFF2 (residing in data-center
2) to Sub-domain#2 to SFF2 to network egress.
</postamble>
</figure>
</section>
<section title="Lower Levels">
<t>
Each of the sub-domains in <xref target="fig_hierarchical_top"/> is an
SFC domain.
</t>
<t>
Unlike the top level, however, data packets entering the sub-domain
are already encapsulated within SFC transport.
<xref target="fig_hierarchical_lower"/> shows a sub-domain interfaced
with a higher-level domain by means of an Internal Boundary Node
(IBN). It is the purpose of the IBN to remove packets from the SFC
encapsulation, apply Classification rules, and direct the packets to
the selected local service function paths terminating at an egress
IBN. The egress SFC Domain Gateway finally restores packets to the
original SFC transport and hands them off to SFFs.
</t>
<t>
Each sub-domain intersects a subset of the total paths that are
possible in the higher-level domain. An IBN is concerned with
higher-level paths, but only those traversing the sub-domain. A
top-level controller may configure the IBN as an SF (the IBN plays the
SF role in the top-level domain).
</t>
<t>
We expect each sub-domain to have a control-plane that can operate
independently of the top-level control-plane. The sub-domain
control-plane configures the classification and forwarding rules in
the sub-domain. The classification rules reside in the IBN, where
packets are moved from SFC encapsulation of the top-level domain to
and from SFC encapsulation of the lower-level domain.
</t>
<figure anchor="fig_hierarchical_lower"
title="Sub-domain within a higher-level domain">
<artwork><![CDATA[
+----+ +-----+ +----------------------+ +-----+
| |SC#1| SFF | | IBN 1 | | SFF |
->| |================* *===============>
| | +-----+ | # (in DC 1) # | +-----+
| CF | | V # |
| | |+---+ +---+| Top domain
| | * * * * *||CF | * * * * * *|SFF|| * * * * *
| | * |+---+ +-+-+| *
+----+ * | | | | | | Sub *
* +-o-o--------------o-o-+ domain*
* SC#2 | |SC#1 ^ ^ #1 *
* +-----+ | | | *
* | V | | *
* | +---+ +------+ | | *
* | |SFF|->|SF#1.1|--+ | *
* | +---+ +------+ | *
* V | *
* +---+ +------+ +---+ +------+ *
* |SFF|->|SF#2.1|->|SFF|->|SF#2.2| *
* +---+ +------+ +---+ +------+ *
* * * * * * * * * * * * * * * * * * * * * *
]]> </artwork>
<postamble>
*** Sub-domain boundary; === top-level chain; --- low-level chain.
</postamble>
</figure>
<t>
If desired, the pattern can be applied recursively. For example,
SF#1.1 in <xref target="fig_hierarchical_lower"/> could be a
sub-domain of the sub-domain.
</t>
</section>
</section>
<section title="Internal Boundary Node (IBN)">
<t>
A network element termed "Internal Boundary Node" (IBN) bridges packets
between domains. It looks like an SF to the higher level, and looks like
a classifier and end-of-chain to the lower level.
</t>
<t>
To achieve the benefits of hierarchy, the IBN should be applying more
granular traffic classification rules at the lower level than the
traffic passed to it. This means that the number of SF Paths within the
lower level is greater than the number of SF Paths arriving to the
IBN.
</t>
<t>
The IBN is also the termination of lower-level SF paths. This is because
the packets exiting lower-level SF paths must be returned to the
higher-level SF paths and forwarded to the next hop in the higher-level
domain.
</t>
<section title="IBN Path Configuration">
<t>
An operator of a lower-level SF Domain may be aware of which
high-level paths transit their domain, or they may wish to accept any
paths.
</t>
<t>
When packets enter the sub-domain, the Path Identifier and Path Index
are re-marked according to the path selected by the classifier.
</t>
<t>
After exiting a path in the sub-domain, packets can be restored to an
upper-level SF path by these methods:
<list style="numbers">
<t>
Stateful per flow,
</t>
<t>
Pushing path identifier into metadata,
</t>
<t>
Using unique lower-level paths per upper-level path.
</t>
</list>
</t>
<section title="Flow-Stateful IBN">
<t>
An IBN can be flow-aware, returning packets to the correct
higher-level SF path on the basis of 5-tuple of packets exiting the
lower-level SF paths.
</t>
<t>
When packets are received by the IBN on a higher-level path, the
encapsulated packets are parsed for IP and transport-layer (TCP or
UDP) coordinates. State is created, indexed by the 5-tuple of
{source-IP, destination-IP, source-port, destination-port and
transport protocol}. The state contains critical fields of the
encapsulating SFC header (or perhaps the entire header).
</t>
<t>
The simplest approach has the packets return to the same IBN at the
end of the chain that classified the packet at the start of the
chain. This is because the required 5-tuple state is rapidly
changing and most efficiently kept locally. If the packet is
returned to a different IBN for egress, 5-tuple state must be
synchronized between the IBNs.
</t>
<t>
When a packet returns to the IBN at the end of a chain, the SFC
header is removed, the packet is parsed for IP and transport-layer
coordinates, and state is retrieved by the 5-tuple of the packet.
The state contains the information required to forward the packet
within the higher-level service chain.
</t>
<t>
State cannot be created by packets arriving from the lower-level
chain; when state cannot be found for such packets, they MUST be
dropped.
</t>
<t>
This stateful approach is limited to use with SFs that retain the
5-tuple of the packet. This approach cannot be used with SFs that
modify the 5-tuple (e.g., as done by a NAT) or otherwise create
packets for new 5-tuples other than those received (e.g., as an HTTP
cache might do to retrieve content on behalf of the original flow).
In both cases, the fundamental problem is the inability to forward
packets when state cannot be found for the packet 5-tuples.
</t>
<t>
In the stateful approach, there are issues caused by the state, such
as how long the state should be maintained (it MUST time out
eventually), as well as whether the state needs to be replicated to
other devices to create a highly available network.
</t>
<t>
It is valid to consider the state disposable after failure, since it
can be re-created by each new packet arriving from the higher-level
domain. For example, if an IBN loses all flow state, the state is
re-created by an end-point retransmitting a TCP packet.
</t>
<t>
If an SFC domain handles multiple network regions (e.g., multiple
private networks), the 5-tuple may be augmented with a 6th
parameter, perhaps using some metadata to identify the network
region.
</t>
<t>
In this stateful approach, it is not necessary for the sub-domain's
control-plane to modify paths when higher-level paths are changed.
The complexity of the higher-level domain does not cause complexity
in the lower-level domain.
</t>
</section>
<section title="Encoding Upper-Level Paths in Metadata">
<t>
An IBN can push the upper-level service path identifier (SPI) and
service index (SI) (or encoding thereof) into a metadata field of
the lower-level encapsulation (e.g., placing upper-level path
information into a metadata field of NSH). When packets exit the
lower-level path, the upper-level SPI and SI can be restored from
the metadata retrieved from the packet.
</t>
<t>
This approach requires the SFs in the path to be capable of
forwarding the metadata and appropriately attaching metadata to any
packets injected for a flow.
</t>
<t>
Using new metadata may inflate packet size when variable-length
metadata (type 2 from <xref target="I-D.ietf-sfc-nsh">NSH</xref>)
is used.
</t>
<t>
It is conceivable that the MD-type 1 Mandatory Context Header fields
of
<xref target="I-D.ietf-sfc-nsh">NSH</xref> are not all relevant to
the lower-level domain. In this case, one of the metadata slots of
the Mandatory Context Header could be repurposed within the
lower-level domain, and restored when leaving.
</t>
<t>
In this metadata approach, it is not necessary for the sub-domain's
controller to modify paths when higher-level paths are changed.
The complexity of the higher-level domain does not cause complexity
in the lower-level domain.
</t>
</section>
<section title="Using Unique Paths per Upper-Level Path">
<t>
In this approach, paths within the sub-domain are constrained so
that a path identifier (of the sub-domain) unambiguously indicates
the egress path (of the upper domain). This allows the original path
information to be restored at sub-domain egress from a look-up table
using the sub-domain path identifier.
</t>
<t>
Whenever the upper-level domain provisions a path via the
lower-level domain, the lower-level domain controller must provision
corresponding paths to traverse the lower-level domain.
</t>
<t>
A down-side of this approach is that the number of paths in the
lower-level domain is multiplied by the number of paths in the
higher-level domain that traverse the lower-level domain.
I.e., a sub-path must be created for each combination of upper Path
identifier and lower path.
</t>
</section>
</section>
<section title="Gluing Levels Together">
<t>
The path identifier or metadata on a packet received by the IBN may be
used as input to reclassification and path selection within the
lower-level domain.
</t>
<t>
In some cases the meanings of the various path IDs and metadata must
be coordinated between domains.
</t>
<t>
One approach is to use well-known identifier values in metadata,
communicated by some organizational registry.
</t>
<t>
Another approach is to use well-known labels for path identifiers or
metadata, as an indirection to the actual identifiers. The actual
identifiers can be assigned by control-plane systems. For example, a
sub-domain classifier could have a policy, "if pathID=classA then
chain packet to path 1234"; the higher-level controller would be
expected to configure the concrete higher-level pathID for classA.
</t>
</section>
</section>
<section title="Sub-domain Classifier" anchor="section_classifier">
<t>
Within the sub-domain (referring to <xref target="fig_hierarchical_lower"/>),
after the IBN removes higher-level encapsulation from incoming packets,
it sends the packets to the classifier, which selects the encapsulation
for the packet within the sub-domain.
</t>
<t>
One of the goals of the hierarchical approach is to make it easy to
have transport-flow-aware service chaining with bidirectional paths. For
example, it is desired that for each TCP flow, the client-to-server
packets traverse the same SFs as the server-to-client packets, but in
the opposite sequence. We call this bidirectional symmetry. If
bidirectional symmetry is required, it is the responsibility of the
control-plane to be aware of symmetric paths and configure the
classifier to chain the traffic in a symmetric manner.
</t>
<t>
Another goal of the hierarchical approach is to simplify the mechanisms
of scaling in and scaling out service functions.
All of the complexities of load-balancing among multiple SFs can be
handled within a sub-domain, under control of the classifier, allowing
the higher-level domain to be oblivious to the existence of multiple SF
instances.
</t>
<t>
Considering the requirements of bidirectional symmetry and
load-balancing, it is useful to have all packets entering a sub-domain
to be received by the same classifier or a coordinated cluster of
classifiers. There are both stateful and stateless approaches to
ensuring bidirectional symmetry.
</t>
</section>
<section title="Control Plane Elements">
<t>
Controllers have been mentioned in this document without much
explanation. Although control protocols have not yet been standardized,
from the point of view of hierarchical service function chaining we have
these expectations:
<list style="symbols">
<t>
Each control-plane instance manages a single level of hierarchy of a
single domain.
</t>
<t>
Each control-plane is agnostic about other levels of hierarchy. This
aspect allows humans to reason about the system within a single
domain and allows control-plane algorithms to use only domain-local
inputs. Top-level control does not need visibility to sub-domain
policies, nor does sub-domain control need visibility to
higher-level policies.
</t>
<t>
Sub-domain control-planes are agnostic about control-planes of other
sub-domains. This allows both humans and machines to manipulate
sub-domain policy without considering policies of other domains.
</t>
</list>
</t>
<t>
Recall that the IBN acts as an SF in the higher-level domain (receiving
SF instructions from the higher-level control-plane) and as a classifier
in the lower-level domain (receiving classification rules from the
sub-domain control-plane). In this view, it is the IBN that glues the
layers together.
</t>
<t>
The above expectations are not intended to prohibit network-wide
control. A control hierarchy can be envisaged to distribute information
and instructions to multiple domains and sub-domains. Control hierarchy
is outside the scope of this document.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The concept of Hierarchical Service Path Domains was introduced in
<xref target="I-D.homma-sfc-forwarding-methods-analysis">
draft-homma-sfc-forwarding-methods-analysis-01</xref>
as a means to improve scalability of service chaining in large networks.
</t>
<t>
The authors would like to thank the following individuals for taking the
time to read and provide valuable feedback:
</t>
<t>
<list style="hanging">
<t> Ron Parker </t>
<t> Christian Jacquenet </t>
<t> Jie Cao </t>
</list>
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Hierarchical service function chaining makes use of service chaining
architecture, and hence inherits the security considerations described
in the architecture document.
</t>
<t>
Furthermore, hierarchical service function chaining inherits security
considerations of the data-plane protocols (e.g., NSH) and control-plane
protocols used to realize the solution.
</t>
<t>
The systems described in this document bear responsibility for
forwarding internet traffic. In some cases the systems are responsible
for maintaining separation of traffic in private networks.
</t>
<t>
This document describes systems within different domains of
administration that must have consistent configurations in order to
properly forward traffic and to maintain private network separation.
Any protocol designed to distribute the configurations must be secure
from tampering.
</t>
<t>
All of the systems and protocols must be secure from modification by
untrusted agents.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&I-D.draft-homma-sfc-forwarding-methods-analysis;
&I-D.draft-ietf-sfc-nsh;
&I-D.draft-ietf-sfc-architecture;
&I-D.draft-ietf-sfc-dc-use-cases;
</references>
<!-- Appendix -->
<section title="Examples of Hierarchical Service Function Chaining">
<t>
The advantage of hierarchical service function chaining compared with
normal or flat service function chaining is that it can reduce the
management complexity significantly. This section discusses examples
that show the advantage of hierarchical service function chaining.
</t>
<section title="Reducing the Number of Service Function Paths">
<t>
In this use case, hierarchical service function chaining is used to
simplify service function chaining management by reducing the number
of Service Function Paths.
</t>
<t>
As shown in <xref target="fig_example_flat"/>,
there are two domains each with different concerns: a Security Domain
that selects Service Functions based on network conditions and an
Optimization Domain that selects Service Functions based on traffic
protocol.
</t>
<t>
There are five security functions deployed in the Security Domain. The
Security Domain operator wants to enforce the five different security
policies, and the Optimization Domain operator wants to apply
different optimization (either cache or video optimization to each of
these two types of traffic. If we use flat SFC (normal branching), 10
SFPs are needed in each domain. In contrast, if we use hierarchical
SFC, only 5 SFPs in Security Domain and 2 SFPs in Optimization
Domain will be required, as shown in
<xref target="fig_example_hsfc"/>.
</t>
<t>
In the flat model, the number of SFPs is the product of the number of
functions in all of the domains. In the hSFC model, the number of SFPs
is the sum of the number of functions. For example, adding a "bypass"
path in the Optimization Domain would cause the flat model to require
15 paths (5 more), but cause the hSFC model to require one more path
in the Optimization Domain.
</t>
<figure anchor="fig_example_flat"
title="Flat SFC (Normal Branching)">
<artwork><![CDATA[
. . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
. +-1---[ ]----------------->[Cache ]------->
. | [ WAF ] . . .
. +-2-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-3---[Anti ]----------------->[Cache ]------->
. | [Virus] . . .
. +-4-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-5-->[ ]----------------->[Cache ]------->
[DPI]--->[CF]---| [ IPS ] . . .
. +-6-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-7-->[ ]----------------->[Cache ]------->
. | [ IDS ] . . .
. +-8-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-9-->[Traffic]--------------->[Cache ]------->
. | [Monitor] . . .
. +-10->[ ]--------------->[Video Opt.]---->
. . . . . . . . . . . . . . . . . . . . . . . . .
]]> </artwork>
<postamble>
The classifier must select paths that determine the combination of
Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt,
3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5: IPS+Cache, 6:IPS+VideoOpt,
7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache,
10:TrafficMonitor+VideoOpt
</postamble>
</figure>
<figure anchor="fig_example_hsfc"
title="Simplified Path Management with Hierarchical SFC">
<artwork><![CDATA[
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
[CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]---->
. | ^ . . | ^ .
. +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ .
. | | . . | | .
. +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ .
. | | . . .
. +----->[ IPS ]-----+ . . . . . . . . . . . . . . . .
. | | .
. +----->[ IDS ]-----+ .
. | | .
. +-->[ Traffic ]----+ .
. [ Monitor ] .
. . . . . . . . . . . . . . .
]]> </artwork>
</figure>
</section>
<section title="Managing a Distributed Data-Center Network">
<t>
Hierarchical service function chaining can be used to simplify
inter-data-center SFC management. In the example of
<xref target="fig_example_hsfc_inter_dc"/>,
shown below, there is a central data center (Central DC)
and multiple local data centers (Local DC#1, #2, #3)
that are deployed in a geographically distributed manner.
All of the data centers are under a single administrative domain.
</t>
<t>
The central DC may have some service functions that the local DC needs,
such that the local DC needs to chain traffic via the central DC.
This could be because:
<list style="symbols">
<t>
Some service functions are deployed as dedicated hardware
appliances, and there is a desire to avoid the capital and
operation expenses (CAPEX and OPEX respectively) of deploying such
service functions in all data centers.
</t>
<t>
Consider the case when service functions are being trialed,
introduced or otherwise handle a relatively small amount of
traffic. It may be cheaper to manage these service functions in a
single central data center and steer packets to the central data
center than to manage these service functions in all data centers.
</t>
</list>
</t>
<figure anchor="fig_example_hsfc_inter_dc"
title="Simplify Inter-DC SFC Management">
<artwork><![CDATA[
+-----------+
|Central DC |
+-----------+
^ ^ ^
| | |
.---|--|---|----.
/ / | | \
/ / | \ \
+-----+ / / | \ \ +-----+
|Local| | / | \ | |Local|
|DC#1 |--|--. | .----|----|DC#3 |
+-----+ | | | +-----+
\ | /
\ | /
\ | /
'----------------'
|
+-----+
|Local|
|DC#2 |
+-----+
]]>
</artwork>
</figure>
<t>
For large data center operators, one local DC may have tens of thousands of servers
and hundred of thousands of virtual machines. SFC can be used to manage user traffic.
For example, SFC can be used to classify user traffic based on service type, DDoS state etc.
</t>
<t>
In such large scale data center, using flat SFC
is very complex, requiring a super-controller to configure all data centers.
For example, any changes
to Service Functions or Service Function Paths in the central DC (e.g., deploying a new SF) would
require updates to all of the Service Function Paths in the local DCs accordingly.
Furthermore, requirements for symmetric paths add additional complexity when
flat SFC is used in this scenario.
</t>
<t>
Conversely, if using hierarchical SFC, each data center can be managed independently
and the management complexity could be reduced significantly. Service Function Paths between
data centers can represent abstract notions without regard to details within data centers.
Independent controllers can be used for the top level (getting packets to pass the correct
data centers) and local levels (getting packets to specific SF instances).
</t>
</section>
</section>
</back>
</rfc>