-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathrfc.txt
2333 lines (1362 loc) · 74.8 KB
/
rfc.txt
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
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
INTERNET-DRAFT M Cieslak
<draft-wilson-wrec-wccp-v2-01.txt> D Forster
G Tiwana
R Wilson
Cisco Systems
03 Apr 2001
Expires Oct 2001
Web Cache Communication Protocol V2.0
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document describes version 2.0 of the Web Cache Communication
Protocol (WCCP). The WCCP V2.0 protocol specifies interactions between
one or more routers and one or more web-caches. The purpose of the
interaction is to establish and maintain the transparent redirection
of selected types of traffic flowing through a group of routers. The
selected traffic is redirected to a group of web-caches with the aim
of optimising resource usage and lowering response times.
The protocol does not specify any interaction between the web-caches
within a group or between a web-cache and a web-server.
2. Definitions
Assignment Method
The method by which redirected packets are distributed between
[Page 1]
web-caches.
Designated Web-Cache.
The web-cache in a web-cache farm responsible for dictating to the
router or routers how redirected traffic should be distributed between
the members of the farm.
Forwarding Method
The method by which redirected packets are transported from router to
web-cache.
Packet Return Method
The method by which packets redirected to a web-cache are returned to
a router for normal forwarding.
Redirection Hash Table.
A 256-bucket hash table maintained by the router or routers. This
table maps the hash index derived from a packet to be redirected to
the IP address of a destination web-cache.
Service Group
A group of one or more routers plus one or more web-caches working
together in the redirection of traffic whose characteristics are part
of the Service Group definition.
Transparent Redirection.
Transparent redirection is a technique used to deploy caching without
the need for reconfiguration of clients or servers. It involves the
interception and redirection of traffic to one or more web-caches by a
router or switch transparently to the end points of the traffic flow.
Usable Web-Cache.
From the viewpoint of a router a web-cache is considered a usable
member of a Service Group when it has sent that web-cache a
WCCP2_I_SEE_YOU message and has received in response a WCCP2_HERE_I_AM
message with a valid "Receive ID".
Web-Cache Farm.
One or more web-caches associated with a router or routers.
[Page 2]
3. Introduction
3.1 Protocol Overview
WCCP V2.0 defines mechanisms to allow one or more routers enabled for
transparent redirection to discover, verify, and advertise
connectivity to one or more web-caches.
Having established connectivity the routers and web-caches form
Service Groups to handle the redirection of traffic whose
characteristics are part of the Service Group definition.
The protocol provides the means to negotiate the specific method
used for load distribution among web-caches and also the method used
to transport traffic between router and cache.
A single web-cache within a Service Group is elected as the designated
web-cache. It is the responsibility of the designated web-cache to
provide routers with the data which determines how redirected traffic
is distributed between the web-caches in the Service Group.
3.2 WCCP V2.0 enhancements
WCCP V2.0 supports the following enhancements to the WCCP V1.0
protocol.
* Multi-Router Support.
WCCP V2.0 allows a farm of web-caches to be attached to more than one
router.
* Multicast Support.
WCCP V2.0 supports multicasting of protocol messages between
web-caches and routers.
* Improved Security.
WCCP V2.0 provides optional authentication of protocol packets
received by web-caches and routers.
* Support for redirection of non-HTTP traffic.
WCCP V2.0 supports the redirection of traffic other than HTTP traffic
through the concept of Service Groups.
* Packet return.
WCCP V2.0 allows a web-cache to decline to service a redirected packet
and to return it to a router to be forwarded. The method by which
packets are returned to a router is negotiable.
[Page 3]
* Alternative Hashing.
WCCP V2.0 allows the designated web-cache to mark individual buckets
in the Redirection Hash Table for a secondary hash. This allows the
traffic being hashed to a particular bucket to be distributed across
the members of a Service Group.
* Multiple Forwarding Methods
WCCP V2.0 allows individual web-caches to negotiate the method by
which packets are forwarded to a web-cache from a router. Packets
may now be forwarded unencapsulated using a Layer 2 destination
address rewrite.
* Multiple Assignment Methods
WCCP V2.0 allows the designated web-cache to negotiate the method by which
packets are distributed between the web-caches in a service group.
Packets may now be assigned using a hashing scheme or a masking scheme.
* Command and Status Information
WCCP V2.0 includes a mechanism to allow a web-cache to pass a command
to the routers in a Service Group. The same mechanism can be employed
by the routers to pass status information to the web-caches in a
Service Group.
4. Protocol Description
4.1 Joining a Service Group
A web-cache joins and maintains its membership of a Service Group by
transmitting a WCCP2_HERE_I_AM message to each router in the Group at
HERE_I_AM_T (10) second intervals. This may be by unicast to each
router or multicast to the configured Service Group multicast
address. The Web Cache Info component in the WCCP2_HERE_I_AM message
identifies the web-cache by IP address. The Service Info component of
the WCCP2_HERE_I_AM message identifies and describes the Service Group in
which the web-cache wishes to participate.
A router responds to a WCCP2_HERE_I_AM message with a WCCP2_I_SEE_YOU
message. If the WCCP2_HERE_I_AM message was unicast then the router will
respond immediately with a unicast WCCP2_I_SEE_YOU message. If the
WCCP2_HERE_I_AM message was multicast the router will respond via the
scheduled multicast WCCP2_I_SEE_YOU message for the Service Group.
A router responds to multicast web-cache members of a Service Group
using a multicast WCCP2_I_SEE_YOU message transmitted at 9 second
intervals with a 10% jitter.
The Router Identity component in a WCCP2_I_SEE_YOU message includes a list
of the web-caches to which the packet is addressed. A web-cache not
[Page 4]
in the list should discard the WCCP2_I_SEE_YOU message.
4.2 Describing a Service Group
The Service Info component of a WCCP2_HERE_I_AM message describes the
Service Group in which a web-cache wishes to participate. A Service
Group is identified by Service Type and Service ID. There are two
types of Service Group:
* Well Known Services
* Dynamic Services.
Well Known Services are known by both routers and web-caches and do
not require a description other than a Service ID.
In contrast Dynamic Services must be described to a router. A router
may be configured to participate in a particular Dynamic Service
Group, identified by Service ID, without any knowledge of the
characteristics of the traffic associated with the Service Group. The
traffic description is communicated to the router in the
WCCP2_HERE_I_AM message of the first web-cache to join the Service
Group. A web-cache describes a Dynamic Service using the Protocol,
Service Flags and Port fields of the Service Info component. Once a
Dynamic Service has been defined a router will discard any subsequent
WCCP2_HERE_I_AM message which contains a conflicting description. A
router will also discard a WCCP2_HERE_I_AM message which describes a
Service Group for which the router has not been configured.
4.3 Establishing Two-Way Connectivity
WCCP V2.0 uses a "Receive ID" to verify two-way connectivity between a
router and a web-cache. The Router Identity Info component of a
WCCP2_I_SEE_YOU message contains a "Receive ID" field. This field is
maintained separately for each Service Group and its value is
incremented each time the router sends a WCCP2_I_SEE_YOU message to
the Service Group.
The "Receive ID" sent by a router is reflected back by a web-cache in
the Web-Cache View Info component of a WCCP2_HERE_I_AM message. A
router checks the value of the "Receive ID" in each WCCP2_HERE_I_AM
message received from a Service Group member. If the value does not
match the "Receive ID" in the last WCCP2_I_SEE_YOU message sent to
that member the message is discarded.
A router considers a web-cache to be a usable member of a Service
Group only after it has sent that web-cache a WCCP2_I_SEE_YOU message
and received a WCCP2_HERE_I_AM message with a valid "Receive ID" in
response.
[Page 5]
4.4 Negotiating the Forwarding Method
A web-cache and router may negotiate the method by which packets are
forwarded to the web-cache by the router.
This negotiation is per web-cache, per Service Group. Thus web-caches
participating in the same Service Group may negotiate different
forwarding methods with the Service Group routers.
A router will advertise the supported forwarding methods for a Service
Group using the optional Capabilities Info component of the
WCCP2_I_SEE_YOU message. The absence of such an advertisement implies
the router supports the default GRE encapsulation method only.
A web-cache will inspect the forwarding method advertisement in the
first WCCP2_I_SEE_YOU message received from a router for a particular
Service Group. If the router does not advertise a method supported by
the web-cache then the web-cache will abort its attempt to join the
Service Group. Otherwise the web-cache will pick one method from those
advertised by the router and specify that in the optional Capabilities
Info component of its next WCCP2_HERE_I_AM message. Absence of a
forwarding method advertisement in a WCCP2_HERE_I_AM message implies
the cache is requesting the default GRE encapsulation method.
A router will inspect the forwarding method selected by a web-cache in
the WCCP2_HERE_I_AM message received in response to a WCCP2_I_SEE_YOU
message. If the selected method is not supported by the router the
router will ignore the WCCP2_HERE_I_AM message. If the forwarding
method is supported the router will accept the web-cache as usable and
add it to the Service Group.
4.5 Negotiating the Assignment Method
A web-cache and router may negotiate the method by which packets are
distributed between the web-caches in a Service Group.
The negotiation is per Service. Thus web-caches participating in
several Service Groups may negotiate a different assignment method for
each Service Group.
A router will advertise the supported assignment methods for a
Service Group using the optional Capabilities Info component of the
WCCP2_I_SEE_YOU message. The absence of such an advertisement implies
the router supports the default Hash assignment method only.
A web-cache will inspect the assignment method advertisement in the
first WCCP2_I_SEE_YOU message received from a router for the Service
Group. If the router does not advertise a method supported by the
[Page 6]
web-cache then the web-cache will abort its attempt to join the
Service Group. Otherwise the web-cache will pick one method from those
advertised by the router and specify that in the optional Capabilities
Info component of its next WCCP2_HERE_I_AM message. Absence of an
assignment method advertisement in a WCCP2_HERE_I_AM message implies
the cache is requesting the default Hash assignment method.
A router will inspect the assignment method selected by a web-cache in
the WCCP2_HERE_I_AM message received in response to a WCCP2_I_SEE_YOU
message. If the selected method is not supported by the router the
router will ignore the WCCP2_HERE_I_AM message. If the assignment
method is supported the router will accept the web-cache as usable and
add it to the Service Group.
4.5 Negotiating the Packet Return Method
A web-cache and router may negotiate the method by which packets are
returned from a web-cache to a router for normal forwarding.
The negotiation is per Service. Thus web-caches participating in
several Service Groups may negotiate a different packet return method
for each Service Group.
A router will advertise the supported packet return methods for a
Service Group using the optional Capabilities Info component of the
WCCP2_I_SEE_YOU message. The absence of such an advertisement implies
the router supports the default GRE packet return method only.
A web-cache will inspect the packet return method advertisement in the
first WCCP2_I_SEE_YOU message received from a router for the Service
Group. If the router does not advertise a method supported by the
web-cache then the web-cache will abort its attempt to join the
Service Group. Otherwise the web-cache will pick one method from those
advertised by the router and specify that method in the optional
Capabilities Info component of its next WCCP2_HERE_I_AM
message. Absence of a packet return method advertisement in a
WCCP2_HERE_I_AM message implies the cache is requesting the default
GRE packet return method.
A router will inspect the packet return method selected by a web-cache
in the WCCP2_HERE_I_AM message received in response to a
WCCP2_I_SEE_YOU message. If the selected method is not supported by
the router the router will ignore the WCCP2_HERE_I_AM message. If the
packet return method is supported the router will accept the web-cache
as usable and add it to the Service Group.
[Page 7]
4.6 Advertising Views of the Service Group
Each router advertises its view of a Service Group via the Router View
Info component in the WCCP2_I_SEE_YOU message it sends to web-caches.
This component includes a list of the useable web-caches in the
Service Group as seen by the router and a list of the routers in the
Service Group as reported in WCCP2_HERE_I_AM messages from
web-caches. A change number in the component is incremented if the
Service Group membership has changed since the last WCCP2_I_SEE_YOU
message sent by the router.
Each web-cache advertises its view of the Service Group via the Web
Cache View Info component in the WCCP2_HERE_I_AM message it sends to
routers in the Service Group. This component includes the list of
routers that have sent the web-cache a WCCP2_I_SEE_YOU message and a
list of web-caches learnt from the WCCP2_I_SEE_YOU messages. The Web
Cache View Info component also includes a change number which is
incremented each time Service Group membership information changes.
4.7 Security
WCCP V2.0 provides a security component in each protocol message to
allow simple authentication. Two options are supported:
* No Security (default)
* MD5 password security
MD5 password security requires that each router and web-cache wishing
to join a Service Group be configured with the Service Group
password. Each WCCP protocol packet sent by a router or web-cache for
that Service Group will contain in its security component the MD5
checksum of the WCCP protocol message (including the WCCP message
header) and a Service Group password. Each web-cache or router in the
Service Group will authenticate the security component in a received
WCCP message immediately after validating the WCCP message header.
Packets failing authentication will be discarded.
4.8 Distribution of Traffic Assignments
WCCP V2.0 allows the traffic assignment method to be negotiated. There
are two types of information to be communicated depending on the
assignment method:
* Hash Tables
* Mask/Value Sets
[Page 8]
4.8.1 Hash Tables
When using hash assignment each router uses a 256-bucket Redirection
Hash Table to distribute traffic for a Service Group across the member
web-caches. It is the responsibility of the Service Group's designated
web-cache to assign each router's Redirection Hash Table.
The designated web-cache uses a WCCP2_REDIRECT_ASSIGNMENT message to
assign the routers' Redirection Hash Tables. This message is
generated following a change in Service Group membership and is sent
to the same set of addresses to which the web-cache sends WCCP2_HERE_I_AM
messages. The designated web-cache will wait 1.5 HERE_I_AM_T
seconds following a change before generating the message in order to
allow the Service Group membership to stabilise.
The Redirection Hash Tables can be conveyed in either an Assignment
Info Component or an Alternate Assignment Component within a
WCCP2_REDIRECT_ASSIGNMENT. Both components contain an Assignment
Key. This will be reflected back to the designated web-cache in
subsequent WCCP2_I_SEE_YOU messages from the routers in the Service
Group. A WCCP2_REDIRECT_ASSIGNMENT may be repeated after HERE_I_AM_T
seconds if inspection of WCCP2_I_SEE_YOU messages indicates a router
has not received an assignment.
A router will flush its Redirection Hash Table if a
WCCP2_REDIRECT_ASSIGNMENT is not received within 5 HERE_I_AM_T seconds
of a Service Group membership change. A router will flush its
Redirection Hash Table if it receives a WCCP2_REDIRECT_ASSIGNMENT
message in which it is not listed.
The designated web-cache lists the web-caches to which traffic should
be distributed in either an Assignment Info Component or an Alternate
Assignment Component within a WCCP2_REDIRECT_ASSIGNMENT message. Only
those web-caches seen by every router in the Service Group are
included.
4.8.2 Mask/Value Sets
When using mask assignment each router uses masks and a table of
values to distribute traffic for a Service Group across the member
web-caches. It is the responsibility of the Service Group's designated
web-cache to assign each router's mask/value sets.
The designated web-cache uses the Alternate Assignment Component in a
WCCP2_REDIRECT_ASSIGNMENT message to assign the routers' mask/value
set. This message is generated following a change in Service Group
membership and is sent to the same set of addresses to which the
web-cache sends WCCP2_HERE_I_AM messages. The designated web-cache
[Page 9]
will wait 1.5 HERE_I_AM_T seconds following a change before generating
the message in order to allow the Service Group membership to
stabilise.
The Alternate Assignment Info component of the
WCCP2_REDIRECT_ASSIGNMENT contains an Assignment Key. This will be
reflected back to the designated web-cache in subsequent
WCCP2_I_SEE_YOU messages from the routers in the Service Group. A
WCCP2_REDIRECT_ASSIGNMENT message may be repeated after HERE_I_AM_T
seconds if inspection of WCCP2_I_SEE_YOU messages indicates a router
has not received an assignment.
A router will flush its mask/value set if a WCCP2_REDIRECT_ASSIGNMENT
is not received within 5 HERE_I_AM_T seconds of a Service Group
membership change. A router will flush its mask/value set if it
receives a WCCP2_REDIRECT_ASSIGNMENT in which it is not listed.
The designated web-cache lists the web-caches to which traffic should
be distributed in the Alternate Assignment Info component of the
WCCP2_REDIRECT_ASSIGNMENT message. Only those web-caches seen by every
router in the Service Group are included.
4.9 Electing the Designated Web-cache
Election of the designated web-cache will take place once a Service
Group membership has stabilised following a change. The designated
web-cache must be receiving a WCCP2_I_SEE_YOU message from every
router in the Service Group.
Election of the designated web-cache is not part of the WCCP
protocol. However it is recommended that the web-cache with the lowest
IP address is selected as designated web-cache for a Service Group.
4.10 Traffic Interception
A router will check packets passing through it against its set of
Service Group descriptions. The Service Group descriptions are
checked in priority order. A packet which matches a Service Group
description is a candidate for redirection to a web-cache in the
Service Group.
A router will not redirect a packet with a source IP address matching
any web-cache in the Service Group.
[Page 10]
4.11 Traffic Redirection
4.11.1 Redirection with Hash Assignment
Redirection with hash assignment is a two-stage process. In the first
stage a primary key is formed from the packet (as defined by the
Service Group description) and hashed to yield an index into the
Redirection Hash Table.
If the Redirection Hash Table entry contains an unflagged web-cache
index then the packet is redirected to that web-cache. If the bucket
is unassigned the packet is forwarded normally. If the bucket is
flagged as requiring a secondary hash then a secondary key is formed
(as defined by the Service Group description) and hashed to yield an
index into the Redirection Hash Table. If the secondary entry contains
a web-cache index then the packet is directed to that web-cache. If the
entry is unassigned the packet is forwarded normally.
4.11.2 Redirection with Mask Assignment
The first step in redirection using the mask assignment method is to
perform a bitwise AND operation between the mask from the first
mask/value set in the Service Group definition and the contents of the
packet. The output of this operation is the set of fields in the packet
which will be used for value matching. The selected fields from the
packet are then compared against each entry in the list of values for
that mask/value set. If a match is found the packet is redirected to
the web-cache associated with the value entry. If no match is found
the process is repeated for each mask/value set defined for the
Service Group. If, after trying all of the mask/value sets defined
for the Service Group, no match is found, the packet is forwarded
normally.
Mask/value sets are processed in the order in which they are
presented in the Alternate Assignment component. Value elements are
compared in the order in which they appear in the mask/value set of which
they are part.
4.12 Traffic Forwarding
WCCP allows the negotiation of the forwarding method between router
and web-cache (See Negotiating the Forwarding Method). The currently
defined forwarding methods are:
* GRE Encapsulated
* Unencapsulated with L2 rewrite
[Page 11]
4.12.1 Forwarding with GRE Encapsulation
Redirected packets are encapsulated in a new IP packet with a GRE [1]
header followed by a four-octet Redirect header.
The GRE encapsulation uses the simple four-octet GRE header with the
two Flags and Version octets set to zero and a Protocol Type of
0x883E.
The Redirect header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| Reserved | Service ID | Alt Bucket | Pri Bucket |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D Dynamic Service
0: Well known service
1: Dynamic service
A Alternative bucket used
0: Primary bucket used
1: Alternative bucket used
Service ID
Service Group identifier
Alt Bucket
Alternative bucket index used to redirect the packet. Only valid
for hash assignment.
Pri Bucket
Primary bucket index used to redirect the packet. Only valid for hash
assignment.
4.12.2 Forwarding with L2 Rewrite
Redirected packets are not encapsulated. The router replaces the
packet's destination MAC address with the MAC address of the target
web-cache.
This forwarding method requires that the target web-cache
be directly-connected to the router at Layer 2. A router will not
allow a web-cache which is not directly attached to negotiate this
forwarding method.
[Page 12]
4.13 Packet Return
WCCP V2.0 allows a web-cache to decline a redirected packet and return
it to a router for normal forwarding as specified by the packet's
destination IP address. The method by which packets are returned from
router to cache is a matter for negotiation (see Negotiating the
Packet Return Method).
When a router receives a returned packet it must not attempt to
redirect that packet back to a web-cache. Two methods are available to
prevent any further redirection:
* Interface Configuration
* Encapsulation
The interface configuration method requires that a router is
configured to inhibit redirection of packets arriving over interfaces
connected to web-caches. Redirection may be disabled for all packets
arriving on an interface or for packets where the source MAC
address is that of a web-cache. This mechanism is efficient but is
topology dependant and thus may not always be suitable. In this case
the packet return method in use is L2.
The encapsulation method requires a web-cache to send returned packets
to a router with encapsulation. Returned packets are encapsulated in a
GRE packet [1] with a Protocol Type of 0x883E and contain the original
Redirect Header or a null Redirect Header if none was present in the
original redirected packet. The receiving router removes the GRE
encapsulation from the packets and forwards them without attempting to
redirect. The packet return method used in this case is GRE.
4.14 Querying Cache Time-Out
If a router does not receive a WCCP2_HERE_I_AM message from a Service
Group member for 2.5 * HERE_I_AM_T seconds it will query the member by
unicasting a WCCP2_REMOVAL_QUERY message to it. The target Service
Group member should respond by sending a series of 3 identical
WCCP2_HERE_I_AM messages, each separated by HERE_I_AM_T/10 seconds.
If a router does not receive a WCCP2_HERE_I_AM message from a Service
Group member for 3 * HERE_I_AM_T seconds it will consider the member
to be unusable and remove it from the Service Group. The web-cache
will no longer appear in the Router View Info component of the
WCCP2_I_SEE_YOU message.
The web-cache will be purged from the assignment data for the Service
Group.
[Page 13]
4.15 Command and Status Information
WCCP V2.0 includes a mechanism to allow web-caches to send commands to
routers within a service group. The same mechanism can be used by the
routers to provide status information to web-caches.
The mechanism is implemented by the Command Extension component. This
component is included in the WCCP2_HERE_I_AM message from a web-cache
passing commands to routers in a Service Group.
If a router needs to send status information to a web-cache it will
include a command in the Command Extension component within its own
WCCP2_I_SEE_YOU message. That command will indicate the type of status
information being carried.
5. Protocol Messages
Each WCCP protocol message is carried in a UDP packet with a
destination port of 2048. There are four WCCP V2.0 messages:
* Here I AM
* I See You
* Redirect Assign
* Removal Query
5.1 'Here I Am' Message
+--------------------------------------+
| WCCP Message Header |
+--------------------------------------+
| Security Info Component |
+--------------------------------------+
| Service Info Component |
+--------------------------------------+
| Web-Cache Identity Info Component |
+--------------------------------------+
| Web-Cache View Info Component |
+--------------------------------------+
| Capability Info Component (optional) |
+--------------------------------------+
|Command Extension Component (optional)|
+--------------------------------------+
[Page 14]
5.2 'I See You' Message
+--------------------------------------+
| WCCP Message Header |
+--------------------------------------+
| Security Info Component |
+--------------------------------------+
| Service Info Component |
+--------------------------------------+
| Router Identity Info Component |
+--------------------------------------+
| Router View Info Component |
+--------------------------------------+
| Assignment Info Component |
| OR |
| Assignment Map Component |
+--------------------------------------+
| Capability Info Component (optional) |
+--------------------------------------+
|Command Extension Component (optional)|
+--------------------------------------+
5.3 'Redirect Assign' Message
+--------------------------------------+
| WCCP Message Header |
+--------------------------------------+
| Security Info Component |
+--------------------------------------+
| Service Info Component |
+--------------------------------------+
| Assignment Info Component |
| OR |
| Alternate Assignment Component |
+--------------------------------------+
5.4 'Removal Query' Message
+--------------------------------------+
| WCCP Message Header |
+--------------------------------------+
| Security Info Component |
+--------------------------------------+
| Service Info Component |
+--------------------------------------+
| Router Query Info Component |
+--------------------------------------+
[Page 15]
5.5 WCCP Message Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
WCCP2_HERE_I_AM (10)
WCCP2_I_SEE_YOU (11)
WCCP2_REDIRECT_ASSIGN (12)
WCCP2_REMOVAL_QUERY (13)
Version
0x200
Length
Length of the WCCP message not including the WCCP Message Header.
5.6 Message Components
Each WCCP message comprises a WCCP Message Header followed by a number of
message components. The defined components are:
* Security Info
* Service Info
* Router Identity Info
* Web-Cache Identify Info
* Router View Info
* Web-Cache View Info
* Assignment Info
* Router Query Info
* Capabilities Info
* Alternate Assignment
* Assignment Map
* Command Extension
Components are padded to align on a four-octet boundary. Each
component has a 4-octet header specifying the component type and
length. Note that the length value does not include the 4-octet
component header.
[Page 16]
5.6.1 Security Info Component
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Option |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Implementation |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
WCCP2_SECURITY_INFO (0)
Length
Length of the remainder of the component.
Security Option
WCCP2_NO_SECURITY (0)
WCCP2_MD5_SECURITY (1)
Security Implementation
If Security Option has the value WCCP2_NO_SECURITY then this field is
not present. If Security Option has the value WCCP2_MD5_SECURITY this
is a 16-octet field containing the MD5 checksum of the WCCP message and
the Service Group password. The maximum password length is 8 octets.
Prior to calculating the MD5 checksum the password should be padded
out to 8 octets with trailing zeros and the Security Implementation
field of the Security Option set to zero. The MD5 checksum is calculated
using the 8 octet padded password and the WCCP message (including the
WCCP Message Header).
[Page 17]
5.6.2 Service Info Component
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type | Service ID | Priority | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port 0 | Port 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port 6 | Port 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
WCCP2_SERVICE_INFO (1)
Length
Length of the remainder of the component.
Service Type
WCCP2_SERVICE_STANDARD (0).
Service is a well known service and is described by the Service ID.
All fields other than Service ID must be zero.
WCCP2_SERVICE_DYNAMIC (1).
Service is defined by the Protocol, Service Flags and Port fields.
Service ID
Service number. A number in the range 0-255. For well known services
numbers in the range 0-50 are reserved. The numbers currently defined
for well known services are:
0x00 HTTP
[Page 18]
Priority
Service priority. The lowest priority is 0, the highest is
255. Packets for redirection are matched against Services in priority
order, highest first. Well known services have a priority of 240.
Protocol
IP protocol identifier
Service Flags
0x0001 Source IP Hash
0x0002 Destination IP Hash
0x0004 Source Port Hash
0x0008 Destination Port Hash
0x0010 Ports Defined.
0x0020 Ports Source.
0x0100 Source IP Alternative Hash
0x0200 Destination IP Alternative Hash
0x0400 Source Port Alternative Hash
0x0800 Destination Port Alternative Hash
The primary hash flags (Source IP Hash, Destination IP Hash, Source
Port Hash, Destination Port Hash) determine the key which will be
hashed to yield the Redirection Hash Table primary bucket index. If
only the Destination IP Hash flag is set then the packet destination
IP address is used as the key. Otherwise if any of the primary hash
flags are set then the key is constructed by XORing the appropriate
fields from the packet with the key (which has an initial value of
zero).
The key is hashed using the following algorithm:
ulong hash = key;
hash ^= hash >> 16;
hash ^= hash >> 8;
return(hash & 0xFF);
If alternative hashing has been enabled for the primary bucket (see
Assignment Info Component) the alternate hash flags (Source IP
Alternative Hash, Destination IP Alternative Hash, Source Port
Alternative Hash, Destination Port Alternative Hash) determine the
key which will be hashed to yield a secondary bucket index. The key
is constructed by XORing the appropriate fields from the packet with
a key (which has an initial value of zero).