Yes, 5.1kΩ (±20%) pulldowns on CC1 and CC2 are required on an UFP to signal that it is an UFP (power sink).
Does this resistance value affect the actual current draw or voltage in the UFP once the DFP communicated that it is capable of providing? for example DFP with usb 3.2 gen 1 (USB 3.0) port with PD is capable of providing 100W (20V 5A) does the UFP can say it wants only 15W (5V 3A)?
No, it only communicates the (initial) role of the port, nothing about power requirements. The only way to have two-way communication about power is using PD signalling, which is also the only way to negotiate a higher voltage than 5V.
Without PD, the UFP merely communicates that it wants power, the DFP communicates (using the strength of its pull-ups) whether you are allowed to draw 3A, 1.5A, or “default USB power” (pre-USB-C rules, more or less). See this comment and this comment for details.
I see the BD91N01NUX is suggested for handling CC logic. To confirm, this only manages the CC functionality and not the USB PHY, correct?
Correct. It simply measures the voltage on the CC lines (with appropriate filtering) and outputs control lines that indicate the status (disconnected/invalid, default USB power available, 1.5A current available, 3A current available) and plug orientation (relevant for USB3).
It is your responsibility to use these control signals to somehow ensure your device’s current draw complies with the requirements.
Does the BD91N01NUX implement the new* specification for billboard?
Not its job, it is not involved in USB2/3 communication at all. Note that implementation of the billboard device class is not required if
- you use USB-C for power only (no USB phy or USB-C alternate mode), or
- you can reduce your power consumption to meet the advertised current without significantly affecting device functionality (e.g. a charge port on a battery-powered device).
What are the key requirements for the USB 2.0 PHY in a Type-C implementation?
I’m not aware of it having any key requirements, those are covered by the USB 2.0 specification, not the Type-C specification.
How does the PHY interface with the CC logic?
It doesn’t.