Skip to main content

Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks
RFC 6307

Revision differences

Document history

Date Rev. By Action
2017-05-16
16 (System) Changed document authors from "Linda Dunbar, Moran Roth, Ronen Solomon" to "Linda Dunbar, Moran Roth, Ronen Solomon, David Black"
2015-10-14
16 (System) Notify list changed from pwe3-chairs@ietf.org, draft-ietf-pwe3-fc-encap@ietf.org to (None)
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-08-22
16 (System) post-migration administrative database adjustment to the Yes position for Adrian Farrel
2012-04-21
16 (System) RFC published
2011-05-10
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-05-10
16 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2011-05-09
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-05-06
16 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-05-05
16 (System) IANA Action state changed to In Progress
2011-05-05
16 Amy Vezza IESG state changed to Approved-announcement sent
2011-05-05
16 Amy Vezza IESG has approved the document
2011-05-05
16 Amy Vezza Closed "Approve" ballot
2011-05-05
16 Amy Vezza Approval announcement text regenerated
2011-05-05
16 Stewart Bryant Ballot writeup text changed
2011-05-04
16 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss
2011-05-04
16 Adrian Farrel [Ballot comment]
Thanks for addressing my issues so speedily. I am now happy to ballot Yes on this document
2011-05-04
16 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from Discuss
2011-05-03
16 (System) New version available: draft-ietf-pwe3-fc-encap-16.txt
2011-04-28
16 Cindy Morgan Removed from agenda for telechat
2011-04-28
16 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-04-28
16 Adrian Farrel
[Ballot discuss]
Updated Discuss after telechat

---

I have one issue I would like to resolve with this document before
moving to a "Yes" ballot. …
[Ballot discuss]
Updated Discuss after telechat

---

I have one issue I would like to resolve with this document before
moving to a "Yes" ballot.

---

I was a little surprised by the mention of MPLS-TP in the Abstract.
I am not sure how "taking advantage of MPLS-TP" is in any way
different from "using an MPLS PW".

It is probably not important, but it feels a bit like marketing-speak
has escaped into your spec.

Later in the document, however, I find:

  MPLS-TP provides mechanisms for communication over MPLS networks with
  very low loss rates and very low probability of reordering, making it
  possible for Fibre Channel ports to be interconnected directly over
  MPLS networks.

I don't see how MPLS-TP provides such mechanisms, but the sentence is
ambiguous because it is not clear from what you have written whether the
networks intrinsically have the qualities described (and MPLS-TP
provides mechanisms for communicating over them) or whether MPLS-TP
somehow enhances the loss rates and reordering probability. In the
first case, this something of a non-statement; in the second case I
don't think it is true. How about cutting this text?

Later still I find:

  FC PW traffic should only traverse controlled MPLS or MPLS-TP
  networks.

Since all MPLS-TP networks are MPLS networks, I suggest you delete
"or MPLS-TP" from this sentence.

similalry, in the next paragraph:

  As a consequence, resilience of the emulated
  FC service to such outages is dependent upon MPLS-TE/MPLS-TP network.
                                          t
I suggest you change "MPLS-TE/MPLS-TP networks." to "the underlying MPLS
network."
2011-04-28
16 Jari Arkko
[Ballot discuss]
I'm not looking to block the document based on this, but I think we should discuss in the IESG telechat about this document …
[Ballot discuss]
I'm not looking to block the document based on this, but I think we should discuss in the IESG telechat about this document and what it expects out of the underlying MPLS network. The combination of requiring no reordering and the possibility of any error resulting in 30-60 second delays at the FC processing level is worrisome. Can this statement from the draft be made precise:

  FC PW traffic should only traverse controlled MPLS or MPLS-TP
  networks. The network should enforce policing of incoming traffic and
  network resource/bandwidth allocation so that the FC PW delivery
  quality can be assured. To extend FC across an uncontrolled network,
  FCIP SHOULD be used instead of an FC PW, see [RFC3821] and
  [FC-BB-6].

What exactly is considered a controlled network? What kind of mechanisms are sufficient for the resource allocation?
2011-04-28
16 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss
2011-04-28
16 Jari Arkko
[Ballot comment]
I'm not looking to block the document based on this, but I think we should discuss in the IESG telechat about this document …
[Ballot comment]
I'm not looking to block the document based on this, but I think we should discuss in the IESG telechat about this document and what it expects out of the underlying MPLS network. The combination of requiring no reordering and the possibility of any error resulting in 30-60 second delays at the FC processing level is worrisome. Can this statement from the draft be made precise:

  FC PW traffic should only traverse controlled MPLS or MPLS-TP
  networks. The network should enforce policing of incoming traffic and
  network resource/bandwidth allocation so that the FC PW delivery
  quality can be assured. To extend FC across an uncontrolled network,
  FCIP SHOULD be used instead of an FC PW, see [RFC3821] and
  [FC-BB-6].

What exactly is considered a controlled network? What kind of mechanisms are sufficient for the resource allocation?
2011-04-28
16 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded
2011-04-27
16 Pete Resnick
[Ballot comment]
I don't think this is worthy of a discuss, but is the byte order for FC PW Control Word (and other items) specified? …
[Ballot comment]
I don't think this is worthy of a discuss, but is the byte order for FC PW Control Word (and other items) specified? Does it need to be in this document?
2011-04-27
16 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-04-27
16 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-04-27
16 Dan Romascanu
[Ballot discuss]
The document has no operational and manageability considerations section, and no reference to the operational and manageability aspects. I would have expected at …
[Ballot discuss]
The document has no operational and manageability considerations section, and no reference to the operational and manageability aspects. I would have expected at least some considerations about the OAM mapping extensions, as the Pseudowire (PW) OAM Message Mapping I-D (draft-ietf-pwe3-oam-msg-map-16.txt) does not cover FC services over PW.
2011-04-27
16 Dan Romascanu
[Ballot discuss]
The documents has no operational and manageability considerations section, and no reference to the operational and manageability aspects. I would have expected at …
[Ballot discuss]
The documents has no operational and manageability considerations section, and no reference to the operational and manageability aspects. I would have expected at least some considerations about the OAM mapping extensions, as the Pseudowire (PW) OAM Message Mapping I-D (draft-ietf-pwe3-oam-msg-map-16.txt) does not cover FC services over PW.
2011-04-27
16 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded
2011-04-26
16 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-04-26
16 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-04-26
16 Stephen Farrell [Ballot comment]
2011-04-26
16 Stephen Farrell
[Ballot discuss]
The text says:

    "FC Primitive Sequence Reduction: a subset of repetitive FC
      Primitive Sequences received from the attached …
[Ballot discuss]
The text says:

    "FC Primitive Sequence Reduction: a subset of repetitive FC
      Primitive Sequences received from the attached FC port at the
      source PE is selected for WAN transmission..."

It's just not clear to me how the subset is selected, though I think
this is most likely just me not understanding (probably 3.3.2).

I expect to clear once this is explained to me:-)
2011-04-26
16 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-04-25
16 Adrian Farrel
[Ballot comment]
Section 3.1

Although you say:

  The fragmentation bits (bits 8-9) are not used by the FC PW protocol.
  These bits may …
[Ballot comment]
Section 3.1

Although you say:

  The fragmentation bits (bits 8-9) are not used by the FC PW protocol.
  These bits may be used in the future for FC specific indications as
  defined in [RFC4385].

It appears from the diagram that you require these bits to be set to
zero, and I suspect that a future extension might interpret the bits.
I think you should be more explicit in the text.

===                                                             

Nits

Section 1
"the TCP protocol"
The P in TCP stands for what? :-)

---

Section 1.1
s/port on far end of the FC link/port on the far end of the FC link/
2011-04-24
16 Adrian Farrel
[Ballot comment]
Section 3.1

Although you say:

  The fragmentation bits (bits 8-9) are not used by the FC PW protocol.
  These bits may …
[Ballot comment]
Section 3.1

Although you say:

  The fragmentation bits (bits 8-9) are not used by the FC PW protocol.
  These bits may be used in the future for FC specific indications as
  defined in [RFC4385].

It appears from the diagram that you require these bits to be set to
zero, and I suspect that a future extension might interpret the bits.
I think you should be more explicit in the text.

===                                                             

Nits

Section 1
"the TCP protocol"
The P in TCP stands for what? :-)

---

Section 1.1
s/port on far end of the FC link/port on the far end of the FC link/

---

Section 1.2

I could probably look this up in the references, but easier to ask you.

Do you mean "continuously" or "continually"?

(several instances)
2011-04-24
16 Adrian Farrel
[Ballot discuss]
I have two issues I would like to resolve with this document before
moving to a "Yes" ballot.

---

I was a little …
[Ballot discuss]
I have two issues I would like to resolve with this document before
moving to a "Yes" ballot.

---

I was a little surprised by the mention of MPLS-TP in the Abstract.
I am not sure how "taking advantage of MPLS-TP" is in any way
different from "using an MPLS PW".

It is probably not important, but it feels a bit like marketing-speak
has escaped into your spec.

Later in the document, however, I find:

  MPLS-TP provides mechanisms for communication over MPLS networks with
  very low loss rates and very low probability of reordering, making it
  possible for Fibre Channel ports to be interconnected directly over
  MPLS networks.

I don't see how MPLS-TP provides such mechanisms, but the sentence is
ambiguous because it is not clear from what you have written whether the
networks intrinsically have the qualities described (and MPLS-TP
provides mechanisms for communicating over them) or whether MPLS-TP
somehow enhances the loss rates and reordering probability. In the
first case, this something of a non-statement; in the second case I
don't think it is true. How about cutting this text?

Later still I find:

  FC PW traffic should only traverse controlled MPLS or MPLS-TP
  networks.

Since all MPLS-TP networks are MPLS networks, I suggest you delete
"or MPLS-TP" from this sentence.

similalry, in the next paragraph:

  As a consequence, resilience of the emulated
  FC service to such outages is dependent upon MPLS-TE/MPLS-TP network.
                                          t
I suggest you change "MPLS-TE/MPLS-TP networks." to "the underlying MPLS
network."

---

This element of the Discuss is for discussion with the IESG. No action 
from the authors is requested.

The procedures for lock-step with ANSI seem worrisome. Do we really need
to go through these hoops, and how vulnerable are we to ANSI delays?

It seems to me that, although [FC-BB-6] is needed in conjunciton to this
spec to get the whole picture, [FC-BB-6] is not actually required as a
normative reference for the understanding of this spec.
2011-04-24
16 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded
2011-04-23
16 Stephen Farrell [Ballot comment]
NSP is used without expansion.
2011-04-23
16 Stephen Farrell
[Ballot discuss]
The text says:

    "FC Primitive Sequence Reduction: a subset of repetitive FC
      Primitive Sequences received from the attached …
[Ballot discuss]
The text says:

    "FC Primitive Sequence Reduction: a subset of repetitive FC
      Primitive Sequences received from the attached FC port at the
      source PE is selected for WAN transmission..."

It's just not clear to me how the subset is selected, though I think
this is most likely just me not understanding (probably 3.3.2).

I expect to clear once this is explained to me:-)
2011-04-23
16 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-04-21
16 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-04-20
16 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-04-19
16 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-04-15
16 Stewart Bryant Placed on agenda for telechat - 2011-04-28 by Stewart Bryant
2011-04-15
16 Stewart Bryant [Note]: 'Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.' added by Stewart Bryant
2011-04-15
16 Stewart Bryant State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup.
2011-04-15
16 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2011-04-15
16 Stewart Bryant Ballot has been issued
2011-04-15
16 Stewart Bryant Created "Approve" ballot
2011-03-31
16 Stewart Bryant Ballot writeup text changed
2011-03-31
16 Stewart Bryant Ballot writeup text changed
2011-03-31
16 Stewart Bryant Ballot writeup text changed
2011-03-14
16 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-03-14
15 (System) New version available: draft-ietf-pwe3-fc-encap-15.txt
2011-03-04
16 Stewart Bryant State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead.<br>To address various LC comments
2011-02-22
16 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Steve Hanna.
2011-02-21
16 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-02-18
16 Amanda Baber
IANA understands that, upon approval of this document, there are two
IANA Actions which need to be completed.

First, in the MPLS Pseudowire Types Registry …
IANA understands that, upon approval of this document, there are two
IANA Actions which need to be completed.

First, in the MPLS Pseudowire Types Registry in the Pseudowire Name
Spaces registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

IANA has previously reserved PW type 0x001F for this draft. IANA will
now make the registration permanent as follows:

PW type Description Reference
-------- -------------- ----------
0x001F FC Port Mode [RFC-to-be]

Second, in the Pseudowire Interface Parameters Sub-TLV type Registry in
the Pseudowire Name Spaces registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

IANA has previously reserved the following values for this draft:

0x12
0x13
0x14
0x15

IANA will now make these permanent registrations with the words
"Reserved by {RFC-to-be]" in the description as follows:

Parameter ID Length Description Reference
--------- --------- ------------------ ----------
0x12 4 Reserved by [RFC-to-be] [RFC-to-be]
0x13 4 Reserved by [RFC-to-be] [RFC-to-be]
0x14 4 Reserved by [RFC-to-be] [RFC-to-be]
0x15 4 Reserved by [RFC-to-be] [RFC-to-be]

IANA understands that these actions are the only IANA Actions that need
to be completed upon approval of this document.
2011-02-16
16 Samuel Weiler Request for Last Call review by SECDIR is assigned to Steve Hanna
2011-02-16
16 Samuel Weiler Request for Last Call review by SECDIR is assigned to Steve Hanna
2011-02-07
16 Amy Vezza Last call sent
2011-02-07
16 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <pwe3@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-pwe3-fc-encap-14.txt> (Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks) to Proposed Standard


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS
  Networks'
  <draft-ietf-pwe3-fc-encap-14.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-fc-encap/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-fc-encap/

2011-02-07
16 Stewart Bryant Ballot writeup text changed
2011-02-07
16 Stewart Bryant Last Call was requested
2011-02-07
16 Stewart Bryant State changed to Last Call Requested from Publication Requested.
2011-02-07
16 Stewart Bryant Last Call text changed
2011-02-07
16 (System) Ballot writeup text was added
2011-02-07
16 (System) Last call text was added
2011-02-07
16 (System) Ballot approval text was added
2011-01-17
16 Cindy Morgan
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he …
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Matthew Bocci (matthew.bocci@alcatel-lucent.com)
Yes, I have reviewed the document and I believe it is ready for
forwading to the IESG.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, the document has received adequate review. The document
received a number of comments during WG last call and been widely
reviewed and discussed in the working group over a long period of
time.



(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No specific concerns.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

I am comfortable that the document represents WG consensus and has
been reviewed by a reasonable number of active WG aprticipants. It
has been devloped over a long period in the WG.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

None indicated.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?


The document passes ID nits.
This document is not subject to MIB doctor or other reviews.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, the references are split appropriately.



(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists, is consistent with the rest of the
document, and with the style of the IANA registries that it requests
allocations from. There are several requests for allocations from the MPLS
PW Type registry and for PW Interface Parameters. It does not request any
new registries or new processes for allocations from registries.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no sections that use a formal language.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

A Fibre Channel pseudowire (PW) is used to carry Fibre Channel
traffic over an MPLS network. This enables service providers to take
advantage of the reliable transport of MPLS-TE/MPLS-TP to offer
"emulated" Fibre Channel services. This document specifies the
encapsulation of Fibre Channel traffic within a pseudowire. It also
specifies the common procedures for using a PW to provide a Fibre
Channel service.

This document is a product of the PWE3 working group.

This document is STANDARDS TRACK.

Working Group Summary
This draft originated as draft-roth-pwe3-fc-encap-01 in 2005, which
contained a basic specification for the transport of FC over MPLS
using PWs. Subsequently, there was significant debate about the
congestion control and QoS implications of FC, which requires a
reliable underlying transport. The document was reviewed by the
transport area resulting in the development of a TCP-friendly
congestion control protocol. However, this protocol was felt to
add significant complexity, and was removed from the draft and instead
the applicability of FC PWs limited to controlled MPLS / MPLS-TP
networks.


Document Quality
There are no concerns about protocol quality.


Personnel
Who is the Document Shepherd for this document?

Matthew Bocci (matthew.bocci@alcatel-lucent.com)

Who is the Responsible Area Director?
Stewart Bryant
2011-01-17
16 Cindy Morgan Draft added in state Publication Requested
2011-01-17
16 Cindy Morgan [Note]: 'Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.' added
2011-01-11
14 (System) New version available: draft-ietf-pwe3-fc-encap-14.txt
2011-01-06
13 (System) New version available: draft-ietf-pwe3-fc-encap-13.txt
2010-08-25
12 (System) New version available: draft-ietf-pwe3-fc-encap-12.txt
2010-06-29
11 (System) New version available: draft-ietf-pwe3-fc-encap-11.txt
2010-02-26
10 (System) New version available: draft-ietf-pwe3-fc-encap-10.txt
2009-01-16
09 (System) New version available: draft-ietf-pwe3-fc-encap-09.txt
2008-08-21
08 (System) New version available: draft-ietf-pwe3-fc-encap-08.txt
2008-01-17
07 (System) New version available: draft-ietf-pwe3-fc-encap-07.txt
2007-10-17
06 (System) New version available: draft-ietf-pwe3-fc-encap-06.txt
2007-09-18
05 (System) New version available: draft-ietf-pwe3-fc-encap-05.txt
2007-07-26
04 (System) New version available: draft-ietf-pwe3-fc-encap-04.txt
2007-04-27
03 (System) New version available: draft-ietf-pwe3-fc-encap-03.txt
2006-10-20
02 (System) New version available: draft-ietf-pwe3-fc-encap-02.txt
2006-06-29
01 (System) New version available: draft-ietf-pwe3-fc-encap-01.txt
2006-03-01
00 (System) New version available: draft-ietf-pwe3-fc-encap-00.txt