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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
|
<pre>Network Working Group R. Weber
Request for Comments: 3643 Brocade
Category: Standards Track M. Rajagopal
Broadcom Corporation
F. Travostino
Nortel Networks
M. O'Donnell
McDATA
C. Monia
Nishan Systems
M. Merhar
Sun Microsystems
December 2003
<span class="h1">Fibre Channel (FC) Frame Encapsulation</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes the common Fibre Channel (FC) frame
encapsulation format and a procedure for the measurement and
calculation of frame transit time through the IP network. This
specification is intended for use by any IETF protocol that
encapsulates FC frames.
<span class="grey">Weber, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
Table Of Contents
<a href="#section-1">1</a>. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Encapsulation Concepts . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. The FC Encapsulation Header. . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. FC Encapsulation Header Format . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. FC Encapsulation Header Validation . . . . . . . . . . . <a href="#page-7">7</a>
3.2.1. Redundancy Based FC Encapsulation
Header Validation. . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.2.2">3.2.2</a>. CRC Based FC Encapsulation Header Validation . . <a href="#page-7">7</a>
<a href="#section-4">4</a>. Measuring Fibre Channel Frame Transit Time . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. The FC Frame . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. FC Frame Content . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.2">5.2</a>. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.3">5.3</a>. FC SOF and EOF . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6">6</a>. Security Considerations. . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8">8</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
Appendix
<a href="#appendix-A">A</a> Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-B">B</a> Encapsulating Protocol Requirements . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-C">C</a> IANA Considerations . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#appendix-D">D</a> Intellectual Property Rights Statement. . . . . . . . . . . . . <a href="#page-17">17</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Scope</span>
This document describes common mechanisms for the transport of Fibre
Channel frames over an IP network, including the encapsulation format
and a mechanism for enforcing the Fibre Channel frame lifetime
limits.
Warning to Readers Familiar With Fibre Channel: Both Fibre Channel
and IETF standards use the same byte transmission order. However, the
bit and byte numbering is different. See <a href="#appendix-A">Appendix A</a> for guidance.
The organization responsible for the Fibre Channel standards (INCITS
Technical Committee T11) has determined that some functions and modes
of operation are not interoperable to the degree required by the IETF
(see FC-MI [<a href="#ref-8" title="November 1">8</a>]). This document includes applicable T11
interoperability determinations in the form of restrictions on the
use of this encapsulation mechanism.
<span class="grey">Weber, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
Use of these mechanisms in an encapsulating protocol requires an
additional document to specify the encapsulating protocol specific
functionality and appropriate security considerations. Because
security considerations for this encapsulation depend on how it is
used by encapsulating protocols, they are taken up in encapsulating
protocol specific documents.
Conventions used in this document
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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> [<a href="#ref-2" title=""Key words for use in RFCs to Indicate Requirement Levels"">2</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Encapsulation Concepts</span>
The smallest unit of data transmission and routing in Fibre Channel
(FC) is the frame. FC frames include a Start Of Frame (SOF), End Of
Frame (EOF), and the contents of the Fibre Channel frame. The Fibre
Channel frame includes a Cyclic Redundancy Check (CRC) code that
provides error detection for the contents of the frame. FC frames
are variable length. To facilitate transporting FC frames over an IP
based transport such as TCP the native FC frame needs to be contained
in (encapsulated in) a slightly larger structure as shown in Figure
1.
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+
Figure 1 - FC frame Encapsulation
The format and content of an FC frame are described in the FC
standards (e.g., FC-FS [<a href="#ref-3" title="October 27">3</a>], FC-SW-2 [<a href="#ref-4" title=" December 12">4</a>], and FC-PI [<a href="#ref-5" title=" December 1">5</a>]). Of
importance to this encapsulation is the FC requirement that all
frames SHALL contain a CRC for detection of transmission errors.
<span class="grey">Weber, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The FC Encapsulation Header</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. FC Encapsulation Header Format</span>
Figure 2 shows the format of the required FC Encapsulation Header.
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|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|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
+---------------+---------------+---------------+---------------+
1| |
+----- Encapsulating Protocol Specific ----+
2| |
+-----------+-------------------+-----------+-------------------+
3| Flags | Frame Length | -Flags | -Frame Length |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [Seconds] |
+---------------------------------------------------------------+
5| Time Stamp [Seconds Fraction] |
+---------------------------------------------------------------+
6| CRC |
+---------------------------------------------------------------+
Figure 2 - FC Encapsulation Header Format
The fields in the FC Encapsulation Header are defined as follows.
Protocol#: The Protocol# field SHALL contain a number that indicates
which encapsulating protocol is employing the FC Encapsulation.
The values in the Protocol# field are assigned by IANA (see
<a href="#appendix-C">Appendix C</a>).
Version: The Version field SHALL contain 0x01 to indicate that this
version of the FC Encapsulation is being used. All other values
are reserved for future versions of the FC Encapsulation.
-Protocol#: The -Protocol# field SHALL contain the one's complement
of the contents of the Protocol# field. FC Encapsulation
receivers SHOULD either validate the CRC or compare the Protocol#
and - Protocol# fields to verify that an FC Encapsulation Header
is being processed according to a policy defined by the
encapsulating protocol.
<span class="grey">Weber, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
-Version: The -Version field SHALL contain the one's complement of
the contents of the Version field. FC Encapsulation receivers
SHOULD either validate the CRC or compare the Version and -Version
fields to verify that an FC Encapsulation Header is being
processed according to a policy defined by the encapsulating
protocol.
Encapsulating Protocol Specific: The usage of these words differs
based on the contents of the Protocol# field, i.e., the usage of
these words is defined by the encapsulating protocol that is
employing this encapsulation.
Flags: The Flags bits provide information about the usage of the
FC Encapsulation Header as shown in Figure 3.
|------------------------Bit--------------------------|
| |
| 0 1 2 3 4 5 |
+--------------------------------------------+--------+
| Reserved | CRCV |
+--------------------------------------------+--------+
Figure 3 - Flags Field Format
Reserved Flags bits: These bits are reserved for use by future
versions of the FC Encapsulation and SHALL be set to zero on send.
Encapsulating protocols employing the encapsulation described in
this specification MAY require checking for zero on receive,
however doing so has the potential to create incompatibilities
with future versions of this encapsulation. Changes in the usage
of the Reserved Flags bits MUST be identified by changes in the
contents of the Version field. Encapsulating protocols employing
the encapsulation described in this specification MUST NOT make
use of the Reserved Flags bits in any fashion other than that
described in this specification.
CRCV (CRC Valid Flag): A CRCV bit value of one indicates that
the contents of the CRC field are valid. A CRCV bit value of zero
indicates that the contents of the CRC field are invalid. The
value of the CRCV bit SHALL be constant for all FC Encapsulation
Headers sent on a given connection.
Frame Length: The Frame Length field contains the length of the
entire FC Encapsulated frame including the FC Encapsulation Header
and the FC frame (including SOF and EOF words). This length is
based on a unit of 32-bit words. All FC frames are 32-bit-word-
aligned and the FC Encapsulation Header is always word-aligned;
therefore a32-bit word length is acceptable.
<span class="grey">Weber, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
-Flags: The -Flags field SHALL contain the one's complement of the
contents of the Flags field. FC Encapsulation receivers SHOULD
either validate the CRC or compare the Flags and -Flags fields to
verify that an FC Encapsulation Header is being processed
according to a policy defined by the encapsulating protocol.
-Frame Length: The -Frame Length field SHALL contain the one's
complement of the contents of the Frame Length field. FC
Encapsulation receivers SHOULD either validate the CRC or compare
the Frame Length and -Frame Length fields to verify that an FC
Encapsulation Header is being processed according to a policy
defined by the encapsulating protocol.
Time Stamp [Seconds]: The Time Stamp [Seconds] field contains zero
or the number of seconds since 0 hour on 1 January 1900 at the
time the FC Encapsulated frame is place in the outgoing data
stream.
Time Stamp [Seconds Fraction]: The Time Stamp [Second Fraction]
field contains the fraction of the second at the time the FC
Encapsulated frame is place in the outgoing data stream. Non-
significant low order bits may be set to zero. Table 1 shows some
example Time Stamp [Seconds Fraction] values.
+------------+--------------------+
| | Time Stamp |
| Second | [Seconds Fraction] |
+------------+--------------------+
| n.50000... | 0x80000000 |
| n.25000... | 0x40000000 |
| n.12500... | 0x20000000 |
+------------+--------------------+
Table 1 Example Time Stamp [Seconds Fraction] values
Note that, since some time in 1968 (second 2,147,483,648) the most
significant bit (bit 0 of Time Stamp [Seconds]) has been set and that
the field will overflow some time in 2036 (second 4,294,967,296).
Should FCIP be in use in 2036, some external means will be necessary
to qualify time relative to 1900 and time relative to 2036 (and other
multiples of 136 years). There will exist a 200-picosecond interval,
henceforth ignored, every 136 years when the 64-bit field will be 0,
which by convention is interpreted as an invalid or unavailable
timestamp.
<span class="grey">Weber, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
The Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words
follow the in time format described in Simple Network Time Protocol
(SNTP) Version 4 [<a href="#ref-9" title=""Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI"">9</a>]. The contents of the Time Stamp [Seconds] and
Time Stamp [Seconds Fraction] words SHALL be set as described in
<a href="#section-4">section 4</a>.
CRC: When the CRCV Flag bit is zero, the CRC field SHALL contain
zero. When the CRCV Flag bit is one, the CRC field SHALL contain a
CRC for words 0 to 5 of the FC Encapsulation Header computed using
the equations, polynomial, initial value, and bit order defined for
Fibre Channel in FC-FS [<a href="#ref-3" title="October 27">3</a>]. Using this algorithm, the bit order of
the resulting CRC corresponds to that of FC-1 layer. The CRC
transmitted over the IP network shall correspond to the equivalent
value converted to FC-2 format as specified in FC-FS.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. FC Encapsulation Header Validation</span>
Two mechanisms are provided for validating an FC Encapsulation
Header:
- Redundancy based
- CRC based
The two mechanisms address the needs of two different design and
operating environments.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Redundancy Based FC Encapsulation Header Validation</span>
Redundancy based validation of an FC Encapsulation Header relies on
duplicated and one's complemented fields in the header.
Encapsulating protocols that use redundancy based validation SHOULD
define how receiving devices use one's complement fields to verify
header validity.
Header validation based on redundancy is a stepwise process in that
the first word is validated, then the second, then the third and so
on. A decision that a candidate header is not valid may be reached
before the complete header is available.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. CRC Based FC Encapsulation Header Validation</span>
CRC based validation of an FC Encapsulation Header relies on a CRC
located in the last word of the header.
Header validation based on the CRC defined in <a href="#section-3.1">section 3.1</a> requires
computing the CRC for all bytes preceding the CRC word, and comparing
the results to the CRC word's contents.
<span class="grey">Weber, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Measuring Fibre Channel Frame Transit Time</span>
To comply with FC-FS [<a href="#ref-3" title="October 27">3</a>], an FC Fabric must specify and limit the
lifetime of a frame. In an FC Fabric comprised of IP-connected
elements, one component of the frame's lifetime is the time required
to traverse the connection. To ensure that the total frame lifetime
remains within the limits required by the FC Fabric, the
encapsulation described in this specification contains provisions for
recording the departure time of an encapsulated frame injected into a
connection. If the encapsulated frame originator and recipient have
access to aligned and synchronized time bases, the transit time
through the IP network can then be computed.
When originating an encapsulated frame, an entity that does not
support transit time calculation SHALL always set the Time Stamp
[Seconds] and Time Stamp [Seconds Fraction] fields to zero. When
receiving an encapsulated frame, an entity that does not support
transit time calculation SHALL ignore the contents of the Time Stamp
words.
The encapsulating protocol SHALL specify whether or not
implementation support is required. The encapsulating protocol SHALL
specify those conditions under which a received encapsulated frame
MUST have its transit time checked before forwarding.
Encapsulating and de-encapsulating entities that support this feature
MUST have access to:
a) An internal time base having the stability and resolution
necessary to comply with the requirements of the encapsulating
protocol specification; and
b) A time base that is synchronized and aligned with the time base of
other entities to which encapsulated frames may be sent or
received. The encapsulating protocol specification MUST describe
the synchronization and alignment procedure.
With respect to its ability to measure and set transit time for
encapsulated frames exchanged with another device, an entity is
either in the Synchronized or Unsynchronized state. An entity is in
the Unsynchronized state upon power-up and transitions to the
Synchronized state once it has aligned its time base in accordance
with the applicable encapsulating protocol specification.
An entity MUST return to the Unsynchronized state if it is unable to
maintain synchronization of its time base as required by the
encapsulating protocol specification.
<span class="grey">Weber, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
The policy for forwarding frames while in the Unsynchronized state
SHALL be defined by the encapsulating protocol specification.
If processing frames in the Unsynchronized state is permitted by the
encapsulating protocol specification, the entity SHALL:
a) When de-encapsulating a frame, ignore the Time Stamp words. For
example, if a calculated transit time exceeds a value that could
cause the frame to violate FC maximum time in transit limits, the
encapsulating protocol may specify that the frame is to be
discarded; and
b) When encapsulating a frame set the Time Stamp [Seconds] and Time
Stamp [Seconds Fraction] words to zero. For example, an
encapsulating protocol may specify that frames for which transit
time cannot be determined are never to be forwarded over FC.
When encapsulating a frame, an entity in the Synchronized state SHALL
record the value of the time base in the Time Stamp [Seconds] and
Time Stamp [Seconds Fraction] words in the encapsulation header.
When de-encapsulating a frame, an entity in the Synchronized state
SHALL:
a) Test the Time Stamp words to determine if they contain a time as
specified in [<a href="#ref-9" title=""Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI"">9</a>]. If the time stamp is valid, the receiving
entity SHALL compute the transit time by calculating the
difference between its time base and the departure time recorded
in the frame header. The receiving entity SHALL process the
calculated transit time and the de-encapsulated frame in
accordance with the applicable encapsulating protocol
specification; or
b) If both Time Stamp words have a value of zero, the receiving
entity SHALL de-encapsulate the frame without computing the
transit time. The disposition of the frame and any other actions
by the recipient SHALL be defined by the encapsulating protocol
specification.
Note: For most purposes, communication between entities is possible
only while in the Synchronized state.
<span class="grey">Weber, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. The FC Frame</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. FC Frame Content</span>
NOTE: All uses of the words "character" or "characters" in this
section refer to 8bit/10bit link encoding wherein each 8 bit
"character" within a link frame is encoded as a 10 bit "character"
for link transmission. These words do not refer to ASCII, Unicode,
or any other form of text characters, although octets from such
characters will occur as 8 bit "characters" for this encoding. This
usage is employed here for consistency with the ANSI T11 standards
that specify Fibre Channel.
Figure 4 shows the structure of a general FC-2 frame format.
+------------------+
| SOF |
+------------------+
| FC frame content |
+------------------+
| EOF |
+------------------+
Figure 4 - General FC-2 Frame Format
As shown in Figure 4, the FC frame content is defined as the data
between the EOF and SOF delimiters (including the FC CRC) after
conversion from FC-1 to FC-2 format as specified by FC-FS [<a href="#ref-3" title="October 27">3</a>].
When Fibre Channel devices convert the FC frame content to the FC-0
physical transport, an encoding is applied to the FC frame content
(e.g., 8b/10b encoding like that used in Gigbit Ethernet) for reasons
that include redundancy and low level timing synchronization between
sender and receiver. With the exceptions of SOF and EOF [<a href="#ref-3" title="October 27">3</a>] all
discussion of FC frame content in this document is at the 8-bit byte
level, prior to the application of any such encoding.
The 8-bit bytes in the FC frame content can be translated directly
for transmission over an IP Network. However, the FC SOF and EOF
employ special 10b characters that have no 8b equivalents. Therefore,
special byte placement and 8-bit character encodings are required to
represent SOF and EOF.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Bit and Byte Ordering</span>
The Encapsulation Header, SOF, FC frame content (see <a href="#section-5.1">section 5.1</a>),
and EOF are mapped to TCP using the big endian byte ordering, which
corresponds to the standard network byte order or canonical form [<a href="#ref-7" title=""A Caution on The Canonical Ordering of Link-Layer Addresses"">7</a>].
<span class="grey">Weber, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. FC SOF and EOF</span>
As described in <a href="#section-5.1">section 5.1</a>, representation of FC SOF and EOF in an
IP Network byte stream requires special formatting and 8-bit code
definitions. Therefore, the encapsulated FC frame SHALL have the
format shown in Figure 5. The redundancy of the SOF/EOF
representation in the encapsulation format results from concerns that
the information be protected from transmission errors.
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|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|
+---------------+---------------+-------------------------------+
0| SOF | SOF | -SOF | -SOF |
+---------------+---------------+-------------------------------+
1| |
+----- FC frame content -----+
| |
+---------------+---------------+-------------------------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+-------------------------------+
Figure 5 - FC Frame Encapsulation Format
Note: The number of 8-bit bytes in the FC frame content is always a
multiple of four.
SOF: The SOF fields contain the encoded SOF value selected from table
2.
+-------+------+-------+ +-------+------+-------+
| FC | SOF | | | FC | SOF | |
| SOF | Code | Class | | SOF | Code | Class |
+-------+------+-------+ +-------+------+-------+
| SOFf | 0x28 | F | | SOFi4 | 0x29 | 4 |
| SOFi2 | 0x2D | 2 | | SOFn4 | 0x31 | 4 |
| SOFn2 | 0x35 | 2 | | SOFc4 | 0x39 | 4 |
| SOFi3 | 0x2E | 3 | +-------+------+-------+
| SOFn3 | 0x36 | 3 |
+-------+------+-------+
Table 2 Translation of FC SOF values to SOF field contents
-SOF: The -SOF fields contain the one's complement of the value in
the SOF fields. Encapsulation receivers SHOULD validate the SOF
field according to a policy defined by the encapsulating protocol.
<span class="grey">Weber, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
EOF: The EOF fields contain the encoded EOF value selected from
table 3.
+-------+------+---------+ +--------+------+-------+
| FC | EOF | | | FC | EOF | |
| EOF | Code | Class | | EOF | Code | Class |
+-------+------+---------+ +--------+------+-------+
| EOFn | 0x41 | 2,3,4,F | | EOFdt | 0x46 | 4 |
| EOFt | 0x42 | 2,3,4,F | | EOFdti | 0x4E | 4 |
| EOFni | 0x49 | 2,3,4,F | | EOFrt | 0x44 | 4 |
| EOFa | 0x50 | 2,3,4,F | | EOFrti | 0x4F | 4 |
+-------+------+---------+ +--------+------+-------+
Table 3 Translation of FC EOF values to EOF field contents
-EOF: The -EOF fields contain the one's complement of the value in
the EOF fields. Encapsulation receivers SHOULD validate the EOF
field according to a policy defined by the encapsulating protocol.
Note: FC-BB-2 [<a href="#ref-6" title="ANSI INCITS.372:2003">6</a>] lists SOF and EOF codes not shown in table 2 and
table 3 (e.g., SOFi1 and SOFn1). However, FC-MI [<a href="#ref-8" title="November 1">8</a>] identifies these
codes as not interoperable, so they are not listed in this
specification.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document describes the encapsulation format only. Actual use of
this format in a encapsulating protocol requires an additional
document to specify the encapsulating protocol functionality and
appropriate security considerations. Because security considerations
for this encapsulation depend on how it is used by encapsulating
protocols, they SHALL be described in encapsulating protocol specific
documents.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Bradner, S., "The Internet Standards Process -- Revision 3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp9">9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.
[<a id="ref-2">2</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="grey">Weber, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
[<a id="ref-3">3</a>] Fibre Channel Framing and Signaling (FC-FS), ANSI
INCITS.373:2003, October 27, 2003. Note: Published T11 standards
are available from the INCITS online store
<a href="http://www.incits.org">http://www.incits.org</a>, or the ANSI online store,
<a href="http://www.ansi.org">http://www.ansi.org</a>.
[<a id="ref-4">4</a>] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:2001,
December 12, 2002. Note: Published T11 standards are available
from the INCITS online store <a href="http://www.incits.org">http://www.incits.org</a>, or the ANSI
online store, <a href="http://www.ansi.org">http://www.ansi.org</a>.
[<a id="ref-5">5</a>] Fibre Channel Physical Interfaces (FC-PI), ANSI NCITS.352:2002,
December 1, 2002. Note: Published T11 standards are available
from the INCITS online store <a href="http://www.incits.org">http://www.incits.org</a>, or the ANSI
online store, <a href="http://www.ansi.org">http://www.ansi.org</a>.
[<a id="ref-6">6</a>] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July
25, 2003. Note: Published T11 standards are available from the
INCITS online store <a href="http://www.incits.org">http://www.incits.org</a>, or the ANSI online
store, <a href="http://www.ansi.org">http://www.ansi.org</a>.
[<a id="ref-7">7</a>] Narten, T. and C. Burton, "A Caution on The Canonical Ordering
of Link-Layer Addresses", <a href="./rfc2469">RFC 2469</a>, December 1998.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-8">8</a>] Fibre Channel Methodologies for Interconnects (FC-MI), ANSI
INCITS/TR-30:2002, November 1, 2002. Note: Published T11
standards are available from the INCITS online store
<a href="http://www.incits.org">http://www.incits.org</a>, or the ANSI online store,
<a href="http://www.ansi.org">http://www.ansi.org</a>.
[<a id="ref-9">9</a>] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", <a href="./rfc2030">RFC 2030</a>, October 1996.
[<a id="ref-10">10</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>, October 1998.
[<a id="ref-11">11</a>] Rajagopal, M., Rodriguez, E., Weber, R., "Fibre Channel Over
TCP/IP (FCIP)", Work in Progress.
[<a id="ref-12">12</a>] Monia, C., et. al., "iFCP - A Protocol for Internet Fibre
Channel Storage Networking", Work in Progress.
<span class="grey">Weber, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
The authors express their appreciation to Mr. Vi Chau
(vchau1@cox.net) for his contributions to the design team that
developed this document. Mr. Chau is no longer working in this
technology.
The authors are also grateful to Dr. David Black, Mr. Mallikarjun
Chadalapaka, and Mr. Robert Elliott for their reviews of this
specification.
<span class="grey">Weber, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
Appendix A - Fibre Channel Bit and Byte Numbering Guidance
Both Fibre Channel and IETF standards use the same byte transmission
order. However, the bit and byte numbering is different.
Fibre Channel bit and byte numbering can be observed if the data
structure heading shown in Figure 6, is cut and pasted at the top of
Figure 2 and Figure 5.
W|------------------------------Bit------------------------------|
o| |
r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 |
d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|
Figure 6 - Fibre Channel Data Structure Bit and Byte Numbering
Fibre Channel bit numbering for the Flags field can be observed if
the data structure heading shown in Figure 7, is cut and pasted at
the top of Figure 3.
|------------------------Bit--------------------------|
| |
| 31 30 29 28 27 26 |
Figure 7 - Fibre Channel Flags Bit Numbering
Appendix B - Encapsulating Protocol Requirements
This appendix lists the requirements placed on the encapsulating
protocols that employ this encapsulation. The requirements listed
here are suggested or described elsewhere in this document, but their
collection in this appendix serves to assist encapsulating protocol
authors in meeting all obligations placed upon them.
Encapsulating Protocol Specific Data
Encapsulating protocols employing this encapsulation SHALL:
- specify the IANA assigned number used in the Protocol# field
- specify the contents of the Encapsulating Protocol Specific field
Encapsulating protocols employing this encapsulation SHALL define the
procedures and policies necessary for verifying that an FC
Encapsulation Header is being processed.
<span class="grey">Weber, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
Encapsulating protocols employing this encapsulation SHALL define the
procedures and policies necessary for the detection of over age
frames. The items to be specified and the choices available to an
encapsulating protocol specification are as follows:
a) The encapsulating protocol requirements for measuring transit
times. The encapsulating protocol MAY allow implementation of
transit time measurement to be optional.
b) The requirements or guidelines for stability and resolution of the
entity's time base.
c) The procedure for synchronizing an entity's time base, including
the criteria for entering the Synchronized and Unsynchronized
states.
d) The forwarding (or lack of forwarding) of frame traffic while in
the Unsynchronized state.
The specification MAY allow an entity in the Unsynchronized state
to continue processing frame traffic.
e) The procedure to be followed when frames are received that do not
have a valid time stamp.
The specification MAY allow such frames to be accepted by the
entity.
f) Requirements for setting and testing the transit time limit and
the procedure to be followed when a received frame is discarded
due to its transit time exceeding the limit.
Appendix C - IANA Considerations
The Protocol# (Protocol Number) field is an identifier number used to
distinguish between the encapsulating protocols that employ this FC
frame encapsulation. Values used in the Protocol# field are to be
assigned from a new, separate registry that is maintained by IANA.
All values in the Protocol# field are to be registered with and
assigned by IANA with the following exceptions.
- Protocol# value 0 should not be assigned until after all other
values have been assigned.
- Protocol# values 240-255 inclusive must be set aside for private
use amongst cooperating systems.
<span class="grey">Weber, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
Following the policies outlined in [<a href="#ref-10" title="">10</a>], Protocol# values not listed
above are to be assigned only for Standards Track RFCs approved by
the IESG.
In addition to creating the FC Frame Encapsulation Protocol Number
Registry, the standards action of this RFC allocates the following
two values from the registry:
- Protocol# value 1 assigned to the FCIP (Fibre Channel Over TCP/
IP) encapsulating protocol [<a href="#ref-11" title=""Fibre Channel Over TCP/IP (FCIP)"">11</a>].
- Protocol# value 2 assigned to the iFCP (A Protocol for Internet
Fibre Channel Storage Networking) encapsulating protocol [<a href="#ref-12" title=""iFCP - A Protocol for Internet Fibre Channel Storage Networking"">12</a>].
Appendix D - Intellectual Property Rights Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in <a href="https://www.rfc-editor.org/bcp/bcp11">BCP-11</a>. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
<span class="grey">Weber, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
Authors' Addresses
Ralph Weber
ENDL Texas
representing Brocade Comm.
Suite 102 PMB 178
18484 Preston Road
Dallas, TX 75252
USA
Phone: +1 214 912 1373
EMail: roweber@ieee.org
Murali Rajagopal
Broadcom
16215 Alton Parkway
PO Box 57013
Irvine, CA 92619
USA
Phone: +1 949 450 8700
EMail: muralir@broadcom.com
Franco Travostino
Technology Center
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821
USA
Phone: +1 978 288 7708
EMail: travos@nortelnetworks.com
Michael E. O'Donnell
McDATA Corporation
4 McDATA Parkway
Broomfield, Co. 80021
USA
Phone +1 720 558 4142
Fax +1 720 558 8999
EMail: mike.o'donnell@mcdata.com
<span class="grey">Weber, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
Charles Monia
EMail: cmonia@pacbell.net
Milan J. Merhar
Sun Microsystems
43 Nagog Park
Acton, MA 01720
USA
Phone: +1 978 206 9124
EMail: milan.merhar@sun.com
<span class="grey">Weber, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3643">RFC 3643</a> FC Frame Encapsulation December 2003</span>
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weber, et al. Standards Track [Page 20]
</pre>
|
